Catalog + Payment Portal Integration for Online Stores Sri Lanka | Capricon Mart + Pay

Connecting Capricon Mart's catalog and checkout to Capricon Pay so LankaQR, card, and bank settlements land against the right order automatically—instead of a finance team matching gateway CSVs by hand every evening.

By Manikya SearathnaAugust 29, 2026

Sri Lankan online store finance staff matching payment settlements to catalog orders through Capricon Pay

A Sri Lankan online store accepting LankaQR, a card gateway, and bank transfer usually has three different places where "payment confirmed" gets recorded—the gateway dashboard, the bank statement, and whatever the storefront shows the customer. None of those three are guaranteed to agree, and the person who finds out first is usually the customer, when their paid order still shows pending three days later.

This is a narrower, integration-focused follow-up to E-commerce & CMS platform Sri Lanka: catalog, content, and orders. That guide covers the platform generally; this one is specifically about connecting catalog and checkout to a centralised payment portal.

What a connected order-to-settlement flow looks like

Customer checks out on the storefront; the order carries a stable reference number.
The chosen payment rail (LankaQR, card, bank transfer) processes the charge against that reference.
Capricon Pay records the settlement and matches it back to the order reference automatically.
Order status updates from pending to paid only once settlement is confirmed—not on gateway response alone, which can show success before funds actually clear.
Refunds and reversals flow back through the same reference so stock and finance both reflect the true state.

Why gateway success and settlement success aren't the same thing

A card gateway can return an authorisation success immediately, but the actual settlement to the merchant account can lag by a day or more, and a small percentage of authorised transactions never settle at all due to disputes or failed capture. Stores that mark an order paid the moment the gateway responds occasionally ship goods against a transaction that later fails to settle.

Order reference matched to LankaQR and card settlement records in Capricon Pay — One reference number, tracked from checkout through settlement—not three dashboards finance has to cross-check by hand.

Reconciliation checklist for a promotion weekend

Confirm every order reference is unique and carried through to the gateway callback—duplicates are the most common matching failure.
Set a clear rule for how long an order can sit pending before support follows up with the customer.
Reconcile gateway fees separately from the order total so net revenue reporting stays accurate.
Flag unmatched settlements (payments with no corresponding order) daily instead of at month-end.
Keep VAT-ready invoice numbering aligned with confirmed-paid orders, not pending ones.

For the compliance side of invoice numbering against confirmed payments, see RAMIS VAT e-invoicing Sri Lanka. For the broader payment-portal case across multiple collection channels, see payment portal software Sri Lanka.

Next steps: e-commerce CMS software Sri Lanka → Capricon Mart → Capricon Pay → contact Capricon to scope the integration.

Frequently asked questions

Why connect the catalog platform to a separate payment portal at all?

Because most Sri Lankan online stores accept more than one payment method—LankaQR, card gateways, bank transfer—and each settles on its own schedule. Without a shared reference between the order and the settlement, someone has to manually match gateway statements to orders every day.

What is Capricon Pay's role next to Capricon Mart?

Mart handles the catalog, cart, and order lifecycle. Capricon Pay centralises collections across payment rails and gives finance one settlement view instead of logging into three gateway dashboards separately.

Does this replace our existing payment gateway?

No. The gateway still processes the transaction. Capricon Pay sits alongside it as the reconciliation and visibility layer, matching what the gateway settled against what the storefront's order record says was charged.

What breaks without this integration?

Orders show as paid on the storefront before settlement confirms, refunds don't reflect back to stock automatically, and finance closes the books on a manual CSV match that's easy to get wrong during a promotion weekend with a spike in orders.