The problem we help solve
A clearer handoff. Less uncertainty.
A shopper reaches the thank-you page, but your store has not received the payment callback. Treating that page visit as payment can release an unpaid order or hide a successful payment from support.
How BrownBag helps
We connect the approved PayHere domain and merchant setup to a store workflow that separates the customer return from server-confirmed payment. The emphasis is on accurate order status and useful exception handling.
From requirement to operation
Your PayHere workflow
Prepare the domain and checkout request
Confirm the merchant account and domain-specific integration approval. Map the order, amount, currency and required customer fields. Generate the request hash on the server so the merchant secret stays outside browser code, and keep sandbox and live settings separate.
Verify the payment notification
Configure a publicly reachable notification endpoint and check the documented checksum before updating an order. Match the incoming merchant, order, amount and currency to the stored transaction. Show the customer a pending status until the server has a verified outcome.
Check failed journeys and staff actions
Test cancellation, failed payment, delayed notification and a repeated callback using the sandbox. Preserve the PayHere payment reference for support. Agree the portal refund process or separately scoped API actions, and document how the team resolves an order that still appears unpaid.
What we can deliver
- Domain-specific checkout configuration and field mapping
- Checksum-verified notification handler and order statuses
- Sandbox scenarios and payment-investigation instructions
We agree the systems, responsibilities, acceptance checks and support arrangements before implementation begins.
Define the right scope
PayHere accepts merchant applications from business entities in Sri Lanka. Accepting international customers does not establish worldwide merchant eligibility. PayHere approves the merchant account, integrating domain and enabled payment facilities. Currency and settlement support must be confirmed for that account. Recurring billing, preapproved charging and authorisation/capture are separate interfaces and require their own consent and operating workflows.
Provider requirements and interfaces can change. We recheck the applicable documentation and account access when scoping your project.
Official PayHere reference →Your questions, answered
Why can the return page show payment pending after a customer pays?
PayHere sends payment status to the server notification URL, not as status parameters on the customer return URL. If that notification has not yet been verified, the page should display the stored pending state and update when confirmation arrives.
What should we include in the first brief?
Share your current store and systems, provider account status, target markets and the workflow you want to improve. Include typical volumes and the person responsible for operations. Do not send passwords, API keys or customer records.