Collect payments
Hosted checkout
How the customer-facing checkout works, the fields it accepts, redirect behaviour and the pending-payment fallback.
5 min read
The three screens
- Method selection — only the gateways enabled for the brand are shown, in the order you set.
- Payment instructions — the number, amount, reference and a copy button, plus any custom instructions.
- TrxID submission — sender number and transaction ID, with duplicate protection against reuse.
Automatic verification
On submit, NaklaPay first looks for an approved SMS on the same gateway with the same TrxID and charged amount. An exact TrxID match is final and settles the invoice immediately.
If the TrxID does not match but a payment-ready SMS is already waiting — same provider and charged amount, a sender match or verified balance, within the last three hours — the checkout settles against it and records the SMS as used by checkout. Only a unique candidate scoring 85 or more is accepted; this covers customers who mistype the last characters of a TrxID.
When an SMS arrives after checkout, the same scoring engine runs in reverse. Each candidate is scored on amount (45), provider (20), sender (25, or −10 on a mismatch), timing (15/8/3) and a verified running balance (+10). Unique matches get +5, ambiguous ones −15. A score of 85 or more with a verified balance or smart checks enabled completes the payment automatically; 55–84 becomes an explainable suggestion in the dashboard. Every score and reason is stored on both the SMS and the payment.
Countdown and expiry
Every invoice carries an expiry time. The hosted checkout shows a live countdown — the chip turns red inside the last two minutes — and closes the payment window when it reaches zero. A charge created through the API expires after 60 minutes by default; pass expires_in (10–1440 minutes) to change it.
Expired invoices reject new TrxID submissions and are marked expired by the background loop. Ask the seller for a fresh link when a customer misses the window.
Instant confirmation
A pending checkout subscribes to a server-sent event stream and flips to the receipt the moment the SMS is matched — no refresh and no waiting for a polling interval. If the stream cannot connect, the page falls back to a four-second poll automatically.
Pending fallback
When no SMS has arrived yet and the gateway has pending payments enabled, the customer sees a success state and the payment is recorded as PENDING. Your team can approve it after checking the statement.
If the delayed SMS arrives later, the automation loop reconciles open payments for up to 24 hours and completes the right one without anyone touching the dashboard. Approving a pending payment manually or from an SMS review also marks the source as manual.
Customisation
- Brand name, logo, accent colour and support contacts come from the active brand.
- Custom instructions per gateway appear under the payment number.
- Meta Pixel can be attached to completed and pending events on Growth and above.
- On Growth and above you can serve checkout from your own domain.
Redirect and cancel URLs
Charges created through the API accept redirect_url and cancel_url. After a completed payment the customer is sent to redirect_url with invoice_id and status appended as query parameters. The cancel URL is used when the customer abandons the page.