BenefitPay is not one integration. For a Bahrain business with a website and a native app, there are two architectures: a gateway web checkout, where the customer leaves to pay on a hosted flow and returns, and an in-app integration, inside your own app. Choosing by default — embedding the web flow because it was fastest, or building natively for an app few install — means paying for the wrong integration twice. This guide makes the choice on evidence: how each route works, what it costs to maintain, and which behaviour decides it. Architecture only; checkout drop-off diagnosis is a separate question.
The short answer: choose the route your repeat customers actually use
If most first purchases happen on your website and your app has a small, occasional audience, web checkout alone is usually right: one integration, maintained once, for site and app alike. If your app is where repeat customers live — reordering, topping up, checking out weekly — the in-app route earns its cost. Many brands will land on both, sequenced: web first, native when app behaviour proves it. The mistake is choosing without looking at where repeat revenue happens.
The two routes, precisely: gateway web checkout vs in-app integration
The web route means a gateway or payment service provider hosts the payment step: your checkout hands the customer over, the gateway runs the payment through BENEFIT's network, and the customer returns to your confirmation page. Checkout.com's official documentation describes the Benefit Payment Gateway as a redirect flow, via its Flow interface or Payment Setup API (checked 21 October 2026): you build no payment screens, only the handover, return and notifications.
The in-app route means BenefitPay is integrated inside your native app, so the customer authorises payment without leaving its screens and session. That route is proven: BENEFIT and Rain announced Rain as the first crypto platform in Bahrain to integrate BenefitPay in-app, through the network of Central Bank of Bahrain-licensed commercial banks. A regulated platform's launch is not a merchant self-serve product; what it demands of a retailer comes next.
| Question | Web checkout route | In-app route |
|---|---|---|
| Where the customer pays | Hosted gateway flow, then returns | Inside your app, end to end |
| What you build | Handover, return handling, webhooks | Native payment integration in iOS and Android |
| Who maintains the screens | The gateway or PSP | Your app team |
How the web route works: redirect, return, and where the return breaks
The mechanics are simple to describe and easy to get subtly wrong. Your checkout creates a payment; the customer is redirected to the hosted flow, authorises, and returns to an address you supply — while a separate server-to-server notification confirms the real outcome. Design for the gap: the customer's return is a user-experience event, not proof of payment. Confirm orders from the gateway's notification; the return page shows a pending state until it lands.
Inside a native app, a redirect opening an external browser or generic web view can strand the customer: payment completes, the app never regains focus, and support inherits a "did my money go?" conversation. Deep links and app-switch return handling close that gap, and must be specified and tested — failed and cancelled returns included. A web route placed in an app without return engineering is the most common way this architecture disappoints.
How the in-app route works: staying inside your app end to end
In the in-app route, your app presents the payment step itself and hands the customer into BenefitPay authorisation within the same session: basket to confirmation, one context. The customer stays in your design, your language choice and your error handling — the checkout repeat customers stop noticing.
Be precise about what "in-app" demands, because the term is abused. Wrapping the hosted web checkout in an in-app browser frame is not an in-app integration; it is the web route wearing your app's clothes, with the same return risks. A true in-app integration is arranged through BENEFIT and your acquiring relationship, built to their requirements, and certified before live payments. Expect a project, not a setting you toggle — which is why the decision should rest on repeat-customer evidence, not a demo.
The acquirer question: who you register through decides your options
Merchants do not simply "add BenefitPay": acceptance is arranged through an acquiring bank, or a payment service provider connected to BENEFIT's gateway, and that choice shapes which routes are available to you. A PSP route typically offers the hosted web checkout first. Deeper arrangements, including in-app ambitions, are discussed in a direct acquiring relationship.
Ask before signing: does this provider offer BenefitPay as a redirect flow only, or is an in-app route available through them at all? Who certifies our app integration, and who do we call when a return fails in production? Get answers in writing: switching provider later usually means re-integrating, re-testing and re-certifying — the "paying twice" this article exists to prevent. See also our ecommerce web development services.
Money operations per route: capture, refunds, webhooks, reconciliation
On the web route, the gateway's documented model defines what your team can do. In Checkout.com's official documentation (checked 21 October 2026): auto-capture and capture are supported; refunds and partial refunds are supported; recurring payments and chargebacks are marked unsupported; and the webhook set includes payment_pending, payment_capture_pending, payment_captured, payment_canceled and payment_refunded. Confirm the equivalent table with your own acquirer or PSP before relying on any line of it.
Either route, insist on the same discipline. Every order should reconcile three records — order state, provider result, and the settlement actually received — matched by a reference stored at creation. Refunds must run from your own admin workflow. Webhooks must be handled idempotently, because notifications repeat.
Hard constraints both routes share: Bahrain-only, BHD, no assumptions
Some facts do not change with the route: in the official gateway documentation above, the supported country is Bahrain, and processing and settlement currency is BHD only. Plan pricing, refunds and accounting in BHD: a BenefitPay transaction is a Bahrain-market transaction by construction.
Two "no assumptions" follow. First, do not design a subscription model on BenefitPay until your acquirer confirms in writing that your route supports it: in the documented gateway model, recurring payments are unsupported. Second, do not promise a one-click saved-method experience without the same written confirmation. More context: our Bahrain page and its Arabic version.
Maintenance reality: app releases and re-testing vs one web integration
The web route concentrates maintenance in one place: the provider maintains the hosted payment screens, and your job is keeping the integration, return handling and webhooks healthy.
The in-app route distributes maintenance across your release cycle. Every significant app release, OS change or provider requirement change can require payment-flow re-testing on iOS and Android; a payment defect is an app-store release away from a fix, not a deploy away. Budget it as a line: payment regression testing in every release.
The decision test: install base, repeat rate, basket and support load
Decide with four numbers from your own business. Install base: what share of Bahrain customers have your app installed? Repeat rate: how many buy more than once a quarter, and in which channel? Basket pattern: are app orders habitual and quick, where a context switch hurts, or considered purchases where a hosted step is unremarkable? Support load: how many payment contacts are return-flow failures in disguise?
If the app holds the minority of transactions and repeats, web checkout everywhere is the honest architecture; if it holds your repeat engine, in-app stops being a luxury. Where numbers are split, run web first and revisit. If a native build is justified, scope it with custom web application development discipline — defined states, tested returns, one reconciliation model; our guide to web development costs and standards in the UAE — our scoping reference.
Running both routes without double reconciliation chaos
Both routes coexist safely as one system: one order and payment data model, where the route is an attribute of the payment, not a separate ledger. Store the provider reference, route and state history for every attempt, so a customer who fails in the app and pays on the web is one record, not two half-orders. Apply the same webhook handling, refund workflow and daily reconciliation report to both, with channel as a column, not a separate report. If a proposed setup gives you two dashboards, two refund paths and two exception queues, the design — not the routes — is the problem.
FAQ
Is BenefitPay available outside Bahrain or in other currencies?
In the official gateway documentation referenced here, the supported country is Bahrain and the processing and settlement currency is BHD only. Design BenefitPay as a Bahrain-market, BHD method, and confirm your provider's current scope.
Does the Benefit Payment Gateway web route support refunds?
Yes, in Checkout.com's documented model: refunds and partial refunds are supported, with a payment_refunded webhook on refund. Your own acquirer or PSP's documentation governs your route, so confirm the equivalent first.
Can we use BenefitPay for subscriptions or recurring billing?
Do not assume so: in the documented gateway model, recurring payments are marked unsupported. If your model needs recurring billing, get written confirmation from your acquirer for your specific route first.
If we have a website and an app, do we need BenefitPay in both?
Not automatically. Web checkout can serve both, with proper return handling in the app. In-app is justified when app repeat purchasing is high enough to repay owning the payment step.
Who do we register with to accept BenefitPay: BENEFIT directly or an acquirer or PSP?
Through the acquiring side: an acquiring bank or a payment service provider connected to BENEFIT's gateway. Available routes, including any in-app route, depend on that relationship — confirm availability and certification in writing first.
Deciding your BenefitPay architecture before you build twice (CTA)
Bring us your channel numbers — app installs, repeat rate by channel, payment support sources — and we will recommend the route, or sequence, that fits them, in writing. If the evidence justifies a native build, our mobile app development team can scope the in-app integration alongside the web checkout, with one reconciliation model across both. An itemised proposal follows within 24 business hours.
