Connect a payment gateway

A payment gateway is what lets a client pay you online. Once one is connected, DMLY can mint a pay link for an invoice, a booking or a subscription, and you send that link to the client on WhatsApp. Until a gateway is connected you will see No payment gateway is connected yet. Connect one to generate a payment link. and you can only record payments you took yourself. Two things to know before you start, because both cost real money if you get them wrong:

​

Gateways you can connect

Six gateways are built. Anything else is not supported. There is no “sign in with Stripe” button. Connecting is always copying API credentials out of the provider’s dashboard and pasting them into DMLY. The credentials you paste are checked when you connect, so a typo fails at that point rather than at the first real payment.

​

Connect a gateway

​

Take a payment

Most payments are collected against an invoice, and a Subscription always bills through one. But a booking is charged directly against the booking, with no invoice behind it, and Request payment (in the inbox, as a flow node, or as a quick automation action) mints a link for any amount with no invoice either, as does Send payment link in amount mode. Those payments still land in the same ledger. An Order gets an invoice only when you use its Generate invoice action. The steps below are the invoice route. The pay link is always for the current Balance due. If a client part-pays and you share the link again, DMLY re-mints it for what’s still owed rather than charging the original amount twice.

The pay link won't generate

A pay link needs an invoice that can actually be paid. You’ll get an error instead of a link when the invoice is Void, when the invoice has no contact attached, or when the balance is already zero.

​

Payments you took yourself

Cash, a bank transfer, a card machine: record these on the invoice and they land in the same ledger as gateway payments, marked as Succeeded immediately. The methods are Cash, Bank transfer, Credit / debit card, Cheque, EFTPOS and Other. You can also record a payment from a client’s profile, see Client profile.

​

Collect a tip at checkout

Turn this on under Finance → Settings → Invoice. The toggle is Collect tips at checkout. Two more controls appear once it’s on:

• Tip presets (%): a comma-separated list of percentages, e.g. 10, 15, 20. DMLY cleans up whatever you type: only whole numbers from 1–100 survive, duplicates are dropped, and the list is sorted low to high, up to 6 presets. Clear the field entirely and DMLY falls back to 10, 15, 20.
• Allow a custom tip amount: on by default. Turn it off and the client can only pick a preset or no tip, with no free-text field.

​

What the client sees

With tips on, an invoice’s pay link and a booking’s payment link no longer send the client straight to the gateway’s own hosted checkout; they land on a DMLY-hosted page first (still carrying your workspace name and logo), because a gateway checkout has no tip step of its own. That page shows the amount due, a No tip button plus one button per preset (each showing the percentage and the resulting amount), a custom-amount field if you allowed one, and a running total. Continue to secure payment then mints the real gateway checkout for the base amount plus whatever tip was chosen and sends the client there. A tip can never exceed the amount it’s added to (it’s a gratuity, not a surcharge), and that’s enforced on submit, not just in the interface.

​

How a tip is tracked afterward

A tip is never folded into the charge it rides on. DMLY keeps it as a figure of its own everywhere that matters:

• The invoice’s Paid / Partially paid status, and its paid and due amounts, are worked out from the base charge alone. A tip never marks more of the invoice as settled than what was actually billed.
• The client’s statement is credited for the base amount only; a tip leaves no mark on their running balance.
• On Finance → Payments, the Amount column is the full amount charged (base plus tip), and a separate Tip column shows the gratuity on its own, blank when there wasn’t one. The two are never merged into one figure there.
• Refunding a tipped payment at the gateway reverses the whole charge, tip included, and DMLY’s ledger stays symmetric: the client’s balance nets back to zero rather than being left owing the tip back, and their lifetime value on Client profile is never dragged negative by refunding money that was never counted as revenue to begin with.

A pay link skips the tip page even though tips are turned on

Only an invoice’s pay link and a booking’s payment link ever front the tip page. Everything else mints a plain gateway link directly whether tips are on or off: Request payment, Send payment link in amount mode, an Order’s payment, and a subscription’s card-capture link. A gift-card purchase invoice also opts out on its own; you don’t tip on buying a gift card. If a client says they never saw a chance to tip, check which of these routes minted their link.

​

Payment statuses

Statuses only move forward: Pending → Failed → Succeeded → Refunded. A late or out-of-order message from the provider can’t drag a paid invoice back to pending.

​

Sandbox behaviour

When the install runs in sandbox, no gateway is ever contacted. Pay links are fake, predictable URLs shaped like https://pay.demo/<provider>/<reference>, and a charge always succeeds. This lets you walk the whole flow (invoice, link, payment, receipt, statement) without a provider account or real money.

​

What a failed webhook means

The webhook is how the gateway tells DMLY that money moved. Everything downstream (the invoice going Paid, a held appointment slot being confirmed, a receipt) hangs off it. So a webhook problem doesn’t lose the client’s money, it loses DMLY’s knowledge of it. The webhook never arrives (endpoint not added in the provider’s dashboard, or the wrong URL). The client is charged, the provider shows the payment, DMLY shows the invoice still unpaid. Nothing retries, because nothing arrived. Fix the endpoint in the provider’s dashboard; new payments will then reconcile on their own. The webhook is rejected (wrong webhook_secret / webhook_id, or copied from a different environment). Same visible symptom: paid at the provider, unpaid in DMLY. Re-copy the signing secret from the provider into DMLY. The webhook arrives but errors. DMLY retries it. A payment message that fails mid-processing is not treated as already-handled on the retry, so it isn’t silently dropped. The payment doesn’t match anything DMLY expected (for example a charge started outside DMLY). It is still recorded as a payment rather than discarded, so the money is visible even if it isn’t attached to an invoice. The credentials stopped working. If the gateway rejects your key (revoked, rotated, or an expired token), DMLY flips the integration to Error and emails workspace admins once, with the subject Action needed: your Stripe integration was disconnected (or whichever gateway it was), a line naming what stops working until it is fixed, and a Reconnect integration button. One email per outage rather than one per failure, so a dead key does not flood your inbox. Paste fresh credentials to clear it.

An appointment was paid for but isn't confirmed

For a booking that requires payment first, the slot is held and only confirmed when the payment succeeds, which DMLY learns from the webhook. If the webhook doesn’t arrive, the hold lapses and the slot frees up even though the client paid. If a payment for a lapsed hold does arrive, it’s flagged rather than thrown away. See Appointment payments.

​

Saved cards and automatic renewals

Subscriptions can charge a saved card automatically on Stripe, PayPal, Paystack, Razorpay and MyFatoorah. The card is captured through a separate setup link, and no payment is recorded against the subscription at that point. If a renewal charge fails, DMLY retries every 2 days and pauses the subscription after 3 failures, notifying the client each time. See Subscriptions. Stripe, PayPal and Razorpay capture the card without charging it. Paystack and MyFatoorah tokenise the card with a small real charge on the hosted page, so on those two the client does see a charge.

​

Related