In-app · cross-border

International payment app on one SDK — cards, ACH, wallets and crypto inside the same sheet.

topropay's iOS, Android and Web SDKs render one payment sheet that surfaces the right methods per buyer geography — cards, ACH, regional rails, wallets and stablecoins through licensed partner crypto gateways. One authorise endpoint, one PCI L1 vault, one reconciliation feed.

Book an SDK walkthrough Read the API docs
One sheet · five method families · one SDK.
40+
countries reachable from one SDK
300+
methods including cards, ACH, wallets, crypto
iOS · Android · Web
one API behind every SDK
1 ledger
across every connected provider

Key benefits

Why this beats a per-method SDK stack for in app payment solutions

Four properties that show up in production when a single SDK replaces a stack of per-method libraries inside the merchant's app.

  1. 01

    Mobile app payment gateway, embedded

    Drop the iOS / Android SDK into a native app and accept cards, wallets, ACH and crypto without building per-method UI. The SDK renders payment sheets; tokenisation happens on topropay before the PAN ever lands in app memory.

  2. 02

    Web app payment processing in the same API

    Hosted fields, drop-in checkout or a low-level JS client cover web apps. The endpoints are the same the mobile SDK calls; one back-end serves both surfaces.

  3. 03

    International reach with regional rails

    International payment app traffic isn't just card. SEPA, iDEAL, PIX, OXXO, GrabPay, Alipay+, plus ACH on US merchants — each surfaces in the SDK per the buyer's market without forking the app code.

  4. 04

    Crypto stays inside the same API

    A crypto payment app feature ships as an extra method in the SDK. Stablecoins and majors via licensed partner crypto gateways; treasury settles in fiat with optional conversion-on-receipt.

How mobile app payment processing works

From SDK init to reconciled receipt in four steps

What actually happens inside the merchant's app between SDK init and the row that lands in the merchant's general ledger.

  1. 01

    Embed the SDK

    Add the topropay SDK to the iOS, Android or web bundle. Init with a publishable key; tokeniser endpoints, vault hostnames and feature flags come from the dashboard.

  2. 02

    Render the payment sheet

    Call `presentPaymentSheet(amount, currency)` and the SDK renders the per-market method list — cards on top, regional rails, wallets and crypto interleaved per the market's behaviour.

  3. 03

    Tokenise + authorise

    PAN / IBAN / on-chain address captured by the SDK is tokenised against topropay's PCI L1 vault before the app touches it. The authorise call returns the vault token and routing receipt.

  4. 04

    Reconcile in one feed

    All method types — cards, ACH, crypto, wallets — normalise into one reconciliation feed. Daily exports tag rows by method, region and connected provider.

Main use cases

Where an international payment app SDK earns its keep

Six merchant shapes that benefit from running one SDK across mobile + web instead of stacking per-method libraries.

  • Travel

    Cross-border travel and ticketing

    A travel app sells across markets; the SDK surfaces local rails per buyer geography (iDEAL for NL, PIX for BR, ACH for US) plus card on top.

  • Gig

    Two-sided marketplaces and gig apps

    Riders pay through the in-app SDK; couriers receive payouts via the same orchestration layer — ACH in the US, SEPA in the EU, crypto for cross-border.

  • DTC

    DTC native + web apps

    Companion web app for desktop, native iOS / Android for mobile. Same SDK, same vault, same dispute queue.

  • SaaS

    Mobile-first SaaS subscriptions

    In-app subscription onboarding — card or ACH at sign-up, recurring renewals on the platform's recurring engine, no per-rail forks in app code.

  • Crypto

    Crypto-aware fintech apps

    A cryptocurrency payment app surfaces stablecoin on-ramp alongside card top-ups; the SDK exposes both as standard methods inside the same payment sheet.

  • B2B

    B2B billing apps

    ACH payment app inside a B2B billing surface — same SDK, NACHA mandate flow surfaces as an SDK step, recurring debits run through topropay's recurring engine.

Platform features

Capabilities behind the mobile app payment gateway and web client

Nine capabilities the SDK exposes — from the tokeniser to recurring, crypto and the unified dispute queue. One API behind every method.

  • iOS, Android and Web SDKs

    Native SDKs for iOS and Android plus a JS client for web apps; one API contract behind all three.

  • PCI-L1-aligned tokeniser

    PAN, IBAN and crypto address capture happens through the SDK's hosted tokeniser; app code never holds the raw value.

  • Drop-in payment sheet

    Pre-built payment sheet with per-market method ordering; brandable via dashboard CSS tokens.

  • Low-level primitives

    When the drop-in isn't enough, low-level SDK primitives let the merchant build a bespoke sheet around the same tokeniser.

  • Smart routing engine

    Per-transaction scoring on BIN, scheme, currency, country pair — routed across topropay's connected acquirer panel.

  • Recurring / subscriptions

    Card-on-file, ACH recurring and SEPA SDD ride the platform's recurring engine; renewals are server-side.

  • Crypto via partner gateways

    Stablecoins (USDC, USDT) and majors (BTC, ETH) through licensed partner crypto gateways, inside the same SDK.

  • Unified dispute queue

    Chargebacks across providers in one queue; evidence-pack templates per vertical.

  • Unified reconciliation

    Settlements, fees, refunds and chargebacks across every method into one ledger tagged by method, region and provider.

Industry relevance

Built for cross-border consumer + fintech apps across EU, UK, APAC and LATAM

The international payment app surface fits app-first merchants where the buyer base spans multiple geographies on day one — travel, marketplaces, gig platforms, DTC brands with international shipping, mobile-first SaaS, regulated fintech apps and crypto-aware apps that need both fiat and stablecoin rails. Licensed gaming operators with current operating licences in their target markets also fit. The platform does not serve adult-content, unlicensed-gambling or grey-market apps.

  • iOS · Android · Web
  • Cards · ACH · Wallets · Crypto · BNPL
  • EU · UK · APAC · LATAM · NA
  • Sub-merchant or direct MID

Trust & compliance

Compliance posture inherited by every in-app method

One audited platform underpins every method exposed by the SDK; sub-merchants inherit the posture per method rather than carrying separate certifications.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; sub-merchants inherit the posture across every method in the SDK.
SCA & PSD2
Selective 3DS2 surfaced through the SDK on the EU-side card leg; PSD2-compliant without breaking conversion.
ACH / NACHA mandates
NACHA mandate evidence captured inside the SDK's ACH flow; retained per scheme rules for ACH payment app traffic.
Crypto partner-gateway compliance
Crypto rails delivered via licensed partner gateways with VASP / MiCA-relevant authorisations; AML / KYC inherited.
Sanctions & AML alignment
Sanctions screening on onboarding; AML monitoring tuned per merchant vertical, app traffic shape and method mix.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of distribution channel.

Ready to drop in the SDK

Ship one SDK. Reach every market.

A 30-minute SDK walkthrough covers the methods relevant to your app's buyer base, the integration shape that fits your engineering constraints, and a sandbox you can test against before any commercial commitment.

Book an SDK walkthrough Read the API docs

Frequently asked

Buyer questions about international payment app integration on topropay

Definitions, SDK questions, ACH and crypto specifics, the IAP-vs-SDK boundary and the practicalities of running one SDK across mobile and web.

  1. 01

    What does topropay deliver inside an international payment app?

    topropay delivers the unified API, SDK (iOS / Android / Web), PCI L1 vault, smart routing engine and one reconciliation feed. An international payment app drops the SDK in, calls one authorise endpoint and gets cross-border card, ACH, wallet and crypto coverage as a single product surface.

  2. 02

    How does in app payment processing differ from a redirect web checkout?

    in app payment processing runs entirely inside the merchant's native or web app — no browser handoff, no context switch. The SDK renders the payment sheet, the tokeniser captures the credential locally, and the authorise call returns the result without leaving the app. Conversion is materially higher than a browser redirect on mobile.

  3. 03

    Does the mobile app payment gateway support recurring charges?

    Yes. The mobile app payment gateway exposes recurring as a flag on the authorise call — the first charge captures a vault token, subsequent renewals run server-side on topropay's recurring engine with smart retries and account updaters. The app doesn't need to schedule the renewals itself.

  4. 04

    What's the difference between in app payment solutions and in-app purchases?

    In-app purchases (IAP) on iOS and Android are platform-mediated billing for digital goods inside the app stores. in app payment solutions through topropay cover everything else — physical goods, services, subscriptions for non-digital content, peer-to-peer payments, fintech flows — i.e. all the categories where Apple / Google IAP isn't required and the merchant wants direct acquirer pricing.

  5. 05

    How does ach payment app work inside the SDK?

    ach payment app flows present a bank-rail selection inside the payment sheet on US-routed buyers. The user enters routing / account or authorises via instant-account-verification; the SDK captures a NACHA mandate; the authorise call uses topropay's ACH endpoint with the partner ACH processor's settlement timeline.

  6. 06

    Can the same SDK power a crypto payment app surface?

    Yes. A crypto payment app feature ships as an extra method in the SDK. The user picks a token (USDC, USDT, BTC, ETH, etc.), the SDK builds the on-chain request through licensed partner crypto gateways, and the merchant's treasury sees either crypto-native receipts or fiat after conversion-on-receipt — the merchant configures the policy.

  7. 07

    Is the cryptocurrency payment app side regulated?

    cryptocurrency payment app rails are delivered through licensed partner crypto gateways with VASP or MiCA-relevant authorisations in their operating jurisdictions. topropay's own scope is orchestration of those partner connections; AML / KYC posture inherits from the partner per the buyer's market.

  8. 08

    Does web app payment processing share the same back-end?

    Yes. web app payment processing on topropay calls the same authorise / capture / refund endpoints as the mobile SDK. The JS client for web exposes drop-in checkout, hosted fields and low-level primitives — pick the integration shape that matches the web app's PCI / UI constraints.

  9. 09

    How does mobile app payment processing handle 3DS2 challenges?

    mobile app payment processing surfaces 3DS2 challenges inside the SDK's native sheet — the SDK renders the bank-side challenge UI in-app rather than bouncing the user to a browser. Selective challenges per transaction keep approval high without skipping the SCA compliance bar in Europe.

  10. 10

    Does the platform support international payment app coverage outside the EU?

    Yes. international payment app coverage on topropay spans EU, UK, APAC (including SEA, AU / NZ), LATAM (BR, MX, AR, CO) and North America via the connected acquirer panel. India is reachable via licensed partner gateways. Each region brings its own dominant methods — the SDK surfaces them per buyer geography.

  11. 11

    How are refunds handled across mixed-method in-app traffic?

    Refunds run against the vault token issued by the original authorisation. The merchant's back-office (or the operator dashboard) initiates the refund; topropay routes it back through the same provider that captured the original — card refunds to card, ACH refunds to ACH, crypto refunds to the original on-chain address. The app doesn't need per-method refund logic.

  12. 12

    What's the typical integration timeline for the SDK?

    A typical iOS / Android SDK integration runs 2–4 weeks for a single-method launch (card-only) and 4–8 weeks for a multi-method launch covering cards, ACH and one regional rail. Web integration is typically faster — 1–2 weeks for drop-in checkout. Sandbox is available before contract.

  13. 13

    Does the SDK ship a payment-sheet UI or does the merchant build one?

    Both are supported. The drop-in payment sheet is the default — a brandable per-market method list that ships with the SDK. Merchants who want full UI control use the low-level primitives instead and build their own sheet around topropay's tokeniser.

  14. 14

    How does the SDK handle tokenised credentials across sessions?

    Vault tokens issued by the SDK persist on the topropay side keyed to the customer record. The app stores only the token reference (a non-sensitive identifier); subsequent charges call authorise with the token rather than re-capturing the credential. Token rotation and scheme account updaters run server-side.

  15. 15

    What analytics and reporting does the merchant get on in-app traffic?

    Reporting splits by SDK platform (iOS, Android, Web), by method, by region and by connected provider. Approval rate, decline reasons, 3DS challenge outcomes and refund rate are surfaced per slice. CSV export and API access both exist; rows tag back to the original SDK session.

Related

Related on the topropay platform