Verified against: Public OpenAPI 2.0.0 · migration review 2026-08-23

Integration pattern

Keep the merchant key out of your app

A mobile app talks to your backend, not directly to Moneybag's merchant-key API. Your backend creates checkout and verifies the final transaction; the app only opens hosted checkout and displays the result returned by your backend.

Rendering diagram…
The merchant backend owns credentials, checkout creation, and payment verification. The mobile app follows hosted navigation and asks the merchant backend for the order result.
Text alternative

The merchant backend owns credentials, checkout creation, and payment verification. The mobile app follows hosted navigation and asks the merchant backend for the order result.

Return handling

Use a return URL controlled by your application and validate its scheme, host, and path before navigation. Treat every deep link, universal link, or app link parameter as untrusted. A returned status or transaction identifier is a lookup hint, not payment evidence.

App state

Keep a merchant order identifier across app suspension or process restart. When the customer returns, fetch the order from your backend. If verification is not terminal, show a neutral pending state and let the backend reconcile later verification and webhook signals idempotently.

Client technology

The payment flow is based on hosted checkout and ordinary HTTPS calls between your app and your backend. This page does not endorse a mobile SDK, WebView library, test card, polling interval, or certificate-pinning policy. Those choices require review in the context of your app and a verified Moneybag release artifact.