The problem we help solve
A clearer handoff. Less uncertainty.
A local payment method can finish after the customer leaves checkout. If the store expects every result immediately, it may cancel a valid order, reserve stock indefinitely or process the same confirmation twice.
How BrownBag helps
We scope Xendit around the countries, channels and products enabled for your business. The implementation gives customers a clear next step and gives operations one reliable payment state to work from.
From requirement to operation
Your Xendit workflow
Choose channels and the checkout product
Review the account country, supported currencies and activated payment methods. Compare Payment Session, a supported plugin and a custom Payments API flow. Define the stock reservation window and what the buyer sees while payment is still pending.
Handle asynchronous payment events
Link Xendit payment references to your own order records. Verify callback tokens on the server and protect order updates from duplicate or out-of-order events. Keep pending, successful, expired and failed outcomes distinct rather than treating the browser return as the payment result.
Test recovery and customer follow-up
Exercise delayed confirmations, a customer abandoning checkout and a repeated notification. Agree when staff investigate an unresolved payment, release reserved stock or offer a fresh payment attempt. Include supported refund handling and reconciliation references in the handover.
What we can deliver
- Country, channel and checkout-product selection
- Verified event processing and payment-state mapping
- Delayed-payment tests and customer-support playbook
We agree the systems, responsibilities, acceptance checks and support arrangements before implementation begins.
Define the right scope
Payment channels, currencies and activation requirements vary by merchant country and Xendit account. We validate the enabled product before implementation. Payouts, platform subaccounts and subscription billing are separate workflows, with their own permissions and agreed responsibilities.
Provider requirements and interfaces can change. We recheck the applicable documentation and account access when scoping your project.
Official Xendit reference →Your questions, answered
How do you prevent a delayed or repeated callback from causing duplicate fulfilment?
We attach the provider payment reference to one order and make the fulfilment transition safe to repeat. The handler verifies the sender and checks the current state before making a change, while unresolved or conflicting events go to an investigation workflow.
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.