Menu
Talk with sales

Integration questions? [email protected]

Mobile payment processing for EU merchants.

Accept mobile payments across iOS, Android and mobile web through one BazPay integration. Apple Pay, Google Pay and hosted card fields share the same charge object, the same signed webhook stream and the same dashboard.

Built for EU e-commerce sellers, subscription software firms and professional-services businesses. Wallet-first at the top of checkout, card fallback underneath, 3-D Secure 2 only when the risk earns it.

Talk with sales Read the API reference

Why merchants choose BazPay to accept mobile payments

Four things stay true whether your traffic is 100% Apple Pay or a mix of wallets and hosted card fields. They are the reasons product and engineering teams stay on the platform after their first mobile release.

  • One API for every mobile surface

    iOS, Android and mobile web share the same charge object, the same webhook stream and the same dashboard. Accepting mobile payments does not fork your back-end.

  • Wallet-first checkout

    Apple Pay and Google Pay arrive pre-tokenised with biometric authentication done device-side. Fewer form fields, fewer drop-offs, no PAN in the request.

  • PSD2 SCA without the extra tap

    3-D Secure 2.2 runs only when the risk earns it, and PSD2 exemption logic claims TRA and low-value where the rules allow. Wallet transactions are inherently SCA-strong.

  • PCI scope stays at SAQ A

    Hosted fields and the native SDK keep card data inside our PCI DSS Level 1 environment. Your mobile team never touches raw PAN on the device or on the server.

Every mobile surface, one integration

Native iOS and Android SDKs, mobile-web hosted checkout and web-view friendly bindings for PWAs and hybrid apps. Same charge object, same webhook stream, same reporting.

  • iOS

    Native iOS SDK

    Swift SDK renders Apple Pay and secure card entry inside your app. Produces the same charge object as the web integration and shares the same signed webhook stream.

    • Swift
    • Apple Pay
    • Face ID / Touch ID

  • Android

    Native Android SDK

    Kotlin SDK renders Google Pay and secure card entry inside your app, with biometric prompts routed through the platform's own authentication surface.

    • Kotlin
    • Google Pay
    • Biometrics

  • Mobile web

    Responsive hosted checkout

    The hosted checkout scales to phone breakpoints, autoplays wallet buttons when available and falls back to a card field served from our PCI environment.

    • Hosted fields
    • Wallet buttons
    • Fallback card

  • PWA and hybrid

    Web-view friendly

    The JavaScript integration runs in progressive web apps and hybrid app web-views without extra shims. Same tokens, same 3-D Secure 2 flow, same dashboard.

    • PWA
    • React Native web-view
    • Capacitor

Payment-method depth on card and APM processing. Hosted UI options on hosted checkout products.

The life of a mobile charge

Six stages sit between the wallet tap and the reconciled euro. Each stage is visible in the dashboard and each stage change fires a signed webhook keyed to the same charge ID.

  1. Present

    The wallet button appears if the device supports Apple Pay or Google Pay. Otherwise the mobile checkout falls back to hosted card fields.

  2. Authenticate

    The wallet requests Face ID, Touch ID or the platform biometric. Card payments run 3-D Secure 2.2 only when the risk earns it.

  3. Tokenise

    Wallets return a device token; hosted fields exchange the PAN for a network token stored in the gateway vault.

  4. Authorise

    The tokenised charge posts to the acquirer on our EU licence. Response returns the authorisation code and any exemption applied.

  5. Confirm

    The app or mobile page receives the charge state inline. A signed webhook confirms the same event asynchronously to your back-end.

  6. Reconcile

    Settlement events, refunds and disputes fire as signed webhooks keyed to the same charge ID. Reporting collapses across every mobile surface.

One mobile SDK vs a stitched wallet stack

Building against separate wallet SDKs and a card gateway on top adds an integration surface per vendor and multiplies the reconciliation work. A single mobile payment processing platform collapses the surface without giving up wallet coverage.

BazPay mobile SDK compared with a stitched wallet stack
Dimension BazPay (one SDK) Stitched wallet stack
SDK footprint One SDK per platform, one charge object Separate SDK per wallet and per card gateway
PCI scope Merchant SAQ A on hosted fields SAQ D once raw PAN touches the app
Wallet coverage Apple Pay and Google Pay both included Often one, both requires a second integration
Event stream Same signed webhook as web Vendor-specific mobile back-office
SCA handling 3-D Secure 2.2 in-app with fallback Redirect flows that break app state
Tokenisation Network tokens default Vendor-locked mobile tokens

Statement structure on the pricing page. Plugin coverage on integrations.

Features engineered for merchant mobile payments

Every capability below ships on the standard integration. Turn features on with a request flag or a dashboard toggle — no enterprise-tier gate on the primitives.

  • Native SDKs

    Swift and Kotlin SDKs for iOS and Android. Same charge object as the web integration, no separate mobile back-office to maintain.

  • Apple Pay

    Wallet button that only renders on capable devices. Domain verification handled through the dashboard. Device tokens ride the card rail.

  • Google Pay

    Wallet button integrated through the Google Pay API. Cryptogram-backed authorisation with automatic PSD2 exemption where eligible.

  • Hosted fields

    Card, expiry and CVC inputs served from our PCI environment inside your mobile web checkout, keeping annual scope at SAQ A.

  • Network tokenisation

    Visa and Mastercard network tokens replace PAN at storage. Automatic PAN refresh keeps mobile subscribers active after card reissue.

  • 3-D Secure 2.2 engine

    Frictionless flow where the issuer allows it. Native SDK surfaces the challenge in-app; hosted checkout handles the redirect.

  • Signed webhooks

    HMAC-signed, replay-protected events for every state change. One handler, one secret, one catalogue across every mobile surface.

  • Idempotent requests

    Retry-safe create requests keyed to your idempotency header. Mobile networks flake — a duplicated request never becomes a double charge.

One REST call from any mobile surface

The charge object is the unit of work whether the surface is an iOS app, an Android app or a mobile-web checkout. The payment_method flag selects the rail. Idempotency keys keep retries safe over flaky mobile networks. Signed webhooks confirm state changes to your back-end. 

POST /v1/charges
Idempotency-Key: 8f1c-2b3a-9e4d
{
  "amount": 4990,
  "currency": "EUR",
  "payment_method": "apple_pay",
  "apple_pay": { "payment_data": "eyJ2ZXJzaW9u..." },
  "capture": "auto",
  "metadata": { "app_id": "com.acme.shop", "surface": "ios" }
}

Swap apple_pay for google_pay on Android, or for card on hosted-field fallback. The response returns the same canonical charge object with the network authorisation code and any exemption applied. Read the full schema in the API reference.

Where BazPay's mobile payment processing fits

The default configuration already reflects these four merchant profiles. Turn on the ones you need and tune each surface's behaviour against your own traffic.

  • Mobile-first e-commerce

    DTC apps and mobile stores selling physical goods. Apple Pay and Google Pay at the top of checkout, hosted card fields underneath.

  • In-app subscription SaaS

    SaaS teams charging plans from a native app. Network-tokenised card-on-file, MIT exemptions on renewals and dunning-aware retries.

  • Membership and content

    Digital publishers taking membership renewals and single-issue unlocks. Wallet checkout for one-tap purchases in the reader.

  • Professional-services apps

    Booking, invoicing and B2B service apps charging higher tickets. Enforced 3-D Secure 2 over a ceiling you set.

Out of scope for BazPay: adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection and MLM. BazPay does not offer premium-SMS or voucher-based mobile billing.

Security and compliance signals

The mobile stack runs inside a PCI DSS Level 1 environment assessed each year. Hosted fields and the native SDK keep your annual return at merchant SAQ A. PSD2 SCA runs on every card charge with automatic exemption logic; wallet transactions carry inherent device-side authentication.

PCI DSS Level 1
Gateway and acquiring environment assessed annually
Merchant SAQ A
Hosted fields and mobile SDK keep card data out of your stack
PSD2 SCA
3-D Secure 2.2 with automatic exemption logic on every card charge
GDPR
EU data residency; DPA available on request
Scheme registrations
Visa VIRP and Mastercard SPoC/PCI-CP where required

Questions merchants ask first

How do I start accepting mobile payments with BazPay?

Board a merchant account, install the iOS or Android SDK (or the web integration for mobile browsers) and post a first charge from your sandbox app. The same charge object powers wallets, hosted card fields and 3-D Secure 2.2, so your mobile team writes one integration path, not one per surface.

Which mobile wallets are supported for merchant mobile payments?

Apple Pay on iOS and Google Pay on Android. Both ride the card rail with a device or network token, so PAN never touches your app or server. Domain verification for Apple Pay is handled from the dashboard; Google Pay merchant registration is issued when your account is provisioned.

Does BazPay offer SMS mobile payment or premium-SMS billing?

No. BazPay does not operate a premium-SMS or mobile-payment-via-SMS service. Mobile payment processing on the platform runs through card networks (including Apple Pay and Google Pay), EU account-to-account rails and local payment methods — not through carrier billing or premium-SMS shortcodes.

Do you support Paysafecard mobile payment vouchers?

Paysafecard voucher acceptance is not part of the current BazPay payment method catalogue. For EU low-risk merchants, the supported mobile methods are Apple Pay, Google Pay, card checkout and the EU local payment methods listed on the card and APM processing page.

What is the PCI scope for a mobile app that uses the SDK?

The mobile SDK renders card capture inside our PCI DSS Level 1 environment and returns a token to your app. Card data never touches your servers or your build artefact, so most integrations qualify for merchant SAQ A — the shortest annual PCI return.

How does 3-D Secure 2.2 work inside a native app?

The SDK surfaces the issuer challenge in-app through the platform's secure browser view. Where the risk data supports an exemption — TRA, low-value, trusted-beneficiary or MIT — the flow is frictionless. Where a challenge is required, liability shifts to the issuer on approval.

Can I run recurring mobile subscriptions?

Yes. Network-tokenised card-on-file, merchant-initiated exemptions on renewals and dunning-aware retries are supported natively. Reissued cards refresh their token automatically, so subscribers stay active without re-consenting inside the app.

Which merchant profiles are in scope?

Low-risk EU merchants: e-commerce sellers, subscription software firms, professional-services businesses and digital publishers. BazPay does not board adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection or MLM merchants.

Ship a mobile charge today

Open a sandbox account, install the SDK and post your first Apple Pay or Google Pay authorisation in the same afternoon. Prefer a walk-through? A payments specialist can map your wallet coverage, your recurring billing and your payouts alongside your app release plan.

Talk with sales See the payment network gateway