E-commerce Payment Planning Guide for Sri Lanka

Choosing an online payment method is a business and operations decision as much as a technical integration. The checkout must suit customers, confirm payment reliably, support reconciliation and refunds, protect data, and keep working when one part of the journey fails.

Provider availability, onboarding, fees, currencies, and rules change. Verify current details directly with shortlisted providers and your financial or legal advisers. This guide provides the questions to resolve before an e-commerce website development project commits to an integration.

Start with customers and order types

List the people buying, devices used, currencies, average and maximum order value, repeat frequency, delivery regions, and whether payment happens immediately, by deposit, on delivery, by invoice, or through a subscription. Identify corporate buyers who may require quotations or bank transfer rather than consumer checkout.

Offer enough choice to cover meaningful customer needs without making the page confusing or operating many unused integrations. Review current analytics, support questions, failed orders, and customer interviews instead of assuming the team’s preferred method is universal.

Compare the complete commercial terms

Ask each provider about setup and recurring fees, transaction pricing, taxes, currency conversion, settlement schedule, minimums, reserves, refund charges, dispute processes, withdrawal, and hardware or account dependencies. Calculate cost at realistic order values and volumes.

Confirm the legal entity, bank account, documents, security review, and approval time required. Keep provider and merchant accounts in company-controlled ownership. Record renewal and compliance responsibilities.

Do not advertise a payment method before production approval. A technically available sandbox does not guarantee commercial onboarding.

Select the integration pattern

A hosted or redirected checkout can reduce the payment data handled by the store, while an embedded or direct integration may provide more control. Evaluate customer experience, security scope, supported payment methods, mobile behaviour, accessibility, customisation, and maintenance.

Use official maintained software libraries where appropriate and validate their support status. Keep credentials out of browser code and source control. Restrict keys by environment and purpose, rotate them safely, and log administrative changes.

The broader website security checklist should cover access, dependencies, headers, monitoring, and incident response around the payment integration.

Make server-side confirmation authoritative

A return page in the customer’s browser is not reliable proof of payment. Users can close it, reload it, lose the network, or manipulate client data. Confirm status through the provider’s supported server-side verification or signed notification process.

Validate signatures, amount, currency, merchant, order identifier, event type, and expected state. Design idempotency so repeated notifications or clicks do not create duplicate orders or entitlements. Store the provider reference and an audit trail without storing prohibited sensitive data.

Model order and payment states separately. An order may be pending while payment is being verified, paid but awaiting fulfilment, failed and retryable, cancelled, refunded, partially refunded, or disputed. Operations need a safe interface for these states.

Test failures deliberately

Test approved and declined payments, user cancellation, insufficient funds where the sandbox supports it, invalid data, timeout, delayed callback, duplicate callback, wrong amount, unavailable provider, interrupted redirect, and successful payment followed by a temporary store failure.

The customer should receive a clear result and next action without being charged twice. Preserve the cart when a retry is safe. Give support staff enough reference information to investigate without requesting card details.

Run tests on realistic mobile connections and browsers. Include assistive technology, keyboard use, text resizing, and error announcement. The e-commerce conversion guide covers the surrounding product and checkout experience.

Reconcile, refund, and support

Define a daily reconciliation process connecting orders, provider transactions, bank settlement, fees, refunds, and disputes. Automate matching where reliable and keep an exception queue with an owner. Finance and operations should agree on the source of truth.

Document who may issue full or partial refunds, required approval, expected customer communication, fulfilment impact, and accounting treatment. Test the refund path before launch. A refund policy page is only useful when the operational process can honour it.

Monitor payment success by method, provider response codes, checkout abandonment, duplicate attempts, reconciliation exceptions, refunds, disputes, and support time. Alert on sudden changes rather than discovering them from social media complaints.

Keep a contingency path

Decide what happens during provider downtime. Depending on the business, the store may show a clear maintenance message, preserve the cart, offer an approved alternative, accept an unpaid reservation, or pause orders. Do not silently mark transactions successful.

Review provider updates, certificates, APIs, billing policies, and business terms on a schedule. Keep a change log and production test plan. Payment integration is an ongoing service, not a completed code snippet.

Connect the final decision to the small-business website launch checklist and the requirements in your product brief. To scope an implementation or remediation, review e-commerce services or send the current flow through Get Started.