Doku.com Payments on InSales: Hosted Checkout

Oceaninside.com — a Bali-based store selling handmade silver jewelry — needed to take payments from international buyers in multiple currencies. Their platform, InSales, had no native Doku.com integration, so every order meant manual handling. We built a hosted-checkout integration to Doku.com that collects payment abroad and reconciles the order status automatically. The pattern generalizes to any store that needs multi-currency payments InSales doesn't offer out of the box.

Why a hosted (redirect) integration

There are two ways to take card payments: embed the card form in your own checkout (and inherit the full PCI-DSS burden), or hand the shopper off to the gateway's hosted payment page and let the gateway handle the card data. For a small international store, hosted checkout is the right trade: Doku owns the sensitive card capture and 3-D Secure, the store never touches raw card numbers, and compliance scope shrinks dramatically. The cost is an integration that spans three moments — create, redirect, reconcile — each of which has to be handled correctly.

The flow, step by step

• Create — at checkout, our service creates a payment on Doku for that order: amount, currency, order id, and a return URL. Each order gets its own payment page, pre-filled with the order details and the payment methods available in the buyer's region.
• Redirect — the shopper is sent to Doku's secure page to pay. They never enter card data on the InSales storefront.
• Reconcile — after payment, the order status updates automatically in InSales. No manual processing.

The rule that makes it reliable: trust the webhook, not the redirect

The most common way a hosted integration goes wrong is marking an order "paid" when the shopper lands back on the return URL. The browser redirect is not proof of payment — a shopper can close the tab, lose connection, or manipulate the return. The authoritative signal is Doku's server-to-server notification (webhook): Doku calls our endpoint with the payment result, and only that — after we verify its signature — flips the order to paid in InSales via the API. The return URL is used only for UX (a thank-you or retry screen).

A hosted payment integration is only as trustworthy as its notification handling. Verify the gateway's signature, treat the order id as an idempotency key, and never let the browser redirect be the thing that marks money received.WS24 — how we build payment integrations

Idempotency and edge cases

• Idempotency — Doku can send a notification more than once; the order id keys the update so a repeated webhook never double-confirms or corrupts the order.
• Verification first — every notification's signature is checked against the shared secret before anything is written; an unverified call is rejected, not trusted.
• Failed / abandoned payments — a non-success result leaves the order unpaid and recoverable, rather than silently stuck.

Multi-currency for a global audience

Because the store sells worldwide, the payment is created in the buyer's currency and the amount shown on Doku's page matches the storefront exactly — the same discipline that keeps a Markets-style multi-currency setup honest: the price the shopper agreed to is the price the gateway charges, to the cent. Currency mismatches between the store and the payment page are the fastest route to chargebacks, so the create step passes currency explicitly rather than assuming a base.

The result for Oceaninside: international shoppers pay on a secure Doku page in their own currency, and orders reconcile themselves in InSales the moment payment is confirmed — no manual steps, no card data on the store, and no order marked paid until the gateway says so. That's what a hosted payment integration should do.