Get DineKit — Free
Card payments

Take card payments on your restaurant WordPress site

Connect your own Stripe account and accept card payments online for bookings and orders — right on your website, with no redirect. You keep 100%. DineKit never takes a cut; the only fee is Stripe’s own standard processing rate, paid straight to Stripe.

Get DineKit — Free See the live demo

Why taking card payments costs restaurants far more than it should

If you run a restaurant, you are almost certainly paying for card acceptance in more places than you can count. There is the card machine you rent by the month whether it is busy or dead. There is the per-transaction cut on every tap. There is the POS or PSP contract — Toast, Square, SumUp and the rest — that ships you their proprietary hardware and then locks you into their terminals, their app and their rates. And when you finally want to take a payment online as well, you discover the machine on the counter does nothing for your website, so you sign up for a second gateway and start paying twice for the same job.

The deeper problem is not the pennies — it is who owns the relationship. When a platform sits between you and your customer, it is their account the money lands in first. They decide the payout schedule. They can hold funds while a dispute is worked out. In some cases they own the customer data outright, so the diner who paid at your table is, on paper, their customer and not yours. You did the cooking, the service and the marketing, and someone else banks the trust.

None of that is a law of nature. It is a business model — one built on renting you hardware and inserting a middleman into a transaction that could just as easily run through your own merchant account. DineKit takes the middleman out.

Your website, your Stripe account, your money

DineKit is a free, open-source WordPress plugin. When you want to accept cards, you connect your own Stripe account — the merchant account is yours, in your restaurant’s name, settling to your bank on Stripe’s normal schedule. DineKit is not a payment processor and does not sit in the flow of funds. It never charges you a platform fee, a monthly licence or a per-transaction slice. The only money that leaves the transaction is Stripe’s own standard processing fee, and that goes to Stripe, not to us.

Because it is your Stripe account, the customer relationship is yours too. The charge appears under your name on the diner’s statement. The payout lands in your bank. The data lives in your dashboard. There is no platform between you and the person who just ate at your restaurant — DineKit simply wires your website to the card rails you already control.

Payments happen right on your site through Stripe’s native Payment Element. There is no redirect to a third-party checkout and no jarring hand-off that makes diners hesitate. They enter their card on your page, on your domain, and stay there start to finish. The same on-site payment powers both booking deposits and online order payments, so you configure it once and it works everywhere money changes hands.

Everything you need to accept cards online

Built on Stripe’s own Payment Element, wired into DineKit’s bookings and ordering, and verified end-to-end on a real server with live test transactions.

💯

Keep 100% of the sale

DineKit takes no cut, ever. You pay Stripe’s standard rate directly to Stripe, and nothing to us. No monthly platform fee, no licence, no per-order slice.

🏦

Your own merchant account

Connect your own Stripe account with your own keys. The money settles to your bank, the charge shows your name, and the customer relationship stays yours.

🧩

No redirect, on your site

Stripe’s native Payment Element mounts directly on your page. Diners enter their card and complete the payment without ever leaving your domain.

📱

Apple Pay and Google Pay

The Payment Element surfaces Apple Pay and Google Pay for one-tap checkout. DineKit auto-registers your domain with Stripe so wallets light up without manual setup.

🔁

Deposits and order payments

One payment flow covers both taking a deposit against a reservation and charging for a takeaway or online order. Set it up once; it works across the whole platform.

Authorise, then capture on accept

Hold-and-accept orders authorise the card up front and only capture when you accept. Reject an order and the hold is released — no charge, no refund needed.

🔒

Keys encrypted, never in the browser

Your Stripe secret key is encrypted at rest with AES-256 and is never exposed to the browser. Card data never touches your WordPress site, keeping you at PCI SAQ A.

🪝

Webhooks configured for you

DineKit registers the Stripe webhook in your account automatically and captures the signing secret. Payments are confirmed server-side, idempotently, so a dropped connection never loses an order.

DineKit vs a typical restaurant card setup

How connecting your own Stripe account through DineKit compares with renting a card machine or signing into a POS platform like Toast, Square or SumUp.

What you needDineKit + your StripeTypical POS / card machine
Monthly fee to accept cards£0 to DineKit — the plugin is freeMachine rental and/or POS subscription every month
Proprietary hardwareNone required online; a Stripe smart reader if you want card-presentLocked to the vendor’s terminals and dongles
Who takes a cut of the saleOnly Stripe’s standard fee, paid to Stripe. DineKit takes nothingPlatform margin on top of the processing cost
Apple Pay and Google PayBuilt in, domain auto-registeredDepends on the plan; often an add-on or unsupported online
Who owns the funds and the customerYou — your Stripe account, your bank, your dataThe platform’s account first; they can hold funds and own the data
Online and in-person on one systemOne flow for website orders, deposits and POS card-presentOften a separate online gateway — you pay twice
Contract and lock-inNone — open-source plugin, switch or leave any timeFixed-term contracts and hardware you can’t repurpose

How the authorise-and-capture flow protects you and the diner

Not every order should be charged the instant a customer taps pay. A kitchen that is slammed, out of a key ingredient, or closing soon needs the option to accept an order before the money moves. DineKit handles this with Stripe’s authorise-then-capture model, so you are never left refunding a charge you should not have taken in the first place.

When an order comes in on hold-and-accept, DineKit authorises the card up front — the funds are reserved but not taken. If you accept the order, the payment is captured at that moment and the sale is complete. If you reject it, the authorisation is simply released and the customer is never charged, so there is no refund to process and no negative balance to explain. If an order is cancelled after it has already been captured, DineKit issues a refund through Stripe and flags it if that refund ever needs a manual nudge. The same discipline applies to booking deposits: a deposit that confirms a reservation is captured cleanly, and a cancellation triggers the refund and notifies the guest.

Because fulfilment is driven by Stripe webhooks rather than the diner’s browser, a customer who closes the tab the second after paying still gets a confirmed order. The payment is verified on your server, the signature is checked against your endpoint secret, and the same event is never processed twice. It is the boring, robust plumbing that keeps money paths honest.

One card system for online and in person

Most restaurants end up running two payment worlds that never talk to each other: a card machine on the counter for people standing in front of you, and a separate online gateway bolted onto the website for everyone else. Two contracts, two sets of fees, two dashboards to reconcile at the end of the night.

DineKit collapses that into one. The same Stripe account that takes an online order deposit or a takeaway payment on your website also drives card-present payments in person through a Stripe smart reader connected to the DineKit POS. A tap at the table and a payment on the website land in the same place, under the same account, on the same statement to the diner. You reconcile once, you pay one processor, and you stop paying twice for the privilege of accepting a card.

Everything is optional and everything degrades gracefully. Leave Stripe switched off and DineKit still runs your menus, bookings and orders — customers simply pay on collection. Switch it on when you are ready, connect your keys, and card payments light up across the whole platform without you rebuilding anything.

Common questions about card payments in DineKit

Does DineKit take a percentage of my sales?
No. DineKit takes nothing — no platform fee, no per-transaction cut, no monthly licence. The plugin is free and open-source. The only fee on a card payment is Stripe’s own standard processing rate, and that is paid directly to Stripe, never to us. You keep 100% of every sale beyond Stripe’s cost.
How do I connect card payments?
You bring your own Stripe account. In DineKit’s Integrations settings you paste your Stripe keys, run the built-in test-connection check, and DineKit registers the webhook in your Stripe account automatically and captures the signing secret. Your secret key is then encrypted at rest with AES-256. From that point cards are live for both orders and booking deposits.
Do customers get redirected to another site to pay?
No. DineKit uses Stripe’s native Payment Element, which mounts directly on your own page. Diners enter their card details and complete the payment — including 3D Secure where required — without ever leaving your website. It looks and feels like part of your site because it is.
Can customers pay with Apple Pay or Google Pay?
Yes. The Payment Element surfaces Apple Pay and Google Pay for one-tap checkout, and DineKit auto-registers your domain with Stripe during setup so the wallets appear without any manual configuration. A card field is always available as the fallback.
Is it safe to store my Stripe key in WordPress?
Your Stripe secret key is encrypted at rest using AES-256 and is never sent to the browser. Card details themselves never touch your WordPress site — they go straight to Stripe from the Payment Element — which keeps you at the simplest PCI compliance level, SAQ A. Payment confirmation happens server-side via a signed, idempotent webhook.
What happens if I reject or cancel an order that was already paid?
It depends on the stage. On hold-and-accept orders the card is only authorised up front, so rejecting simply releases the hold and the customer is never charged. If a payment was already captured and the order is later cancelled, DineKit issues a refund through Stripe and flags it if the refund needs manual attention. Booking deposits follow the same rule — a cancellation refunds the guest and notifies them.
Can I take card payments in person as well as online?
Yes. The same Stripe account handles card-present payments in person through a Stripe smart reader connected to the DineKit POS, alongside online order payments and booking deposits on your website. One account, one processor, one reconciliation — instead of a separate machine and a separate online gateway.
Do I have to use card payments at all?
No. DineKit runs perfectly with Stripe switched off — menus, bookings and orders all work, with customers paying on collection. Card payments are entirely opt-in. Turn them on whenever you are ready and they apply across the platform.

Card payments plug straight into the rest of DineKit: take deposits on your table booking widget, charge for online orders and takeaway, and run card-present payments in person through the free restaurant POS — all on your own Stripe account, all keeping 100%.

Ready to give it a go?

DineKit is free, self-contained and live in minutes. Own your menus, your bookings and your data.

Get DineKit — Free