Skip to main content
This page is for developers and QA running sandbox orders through headless card and Apple Pay. Widget flows are tested with the White-Label API and Meld Checkout testing credentials, and virtual accounts with Virtual Account Flow Testing Credentials.

​
What you can verify

The order call, the capture surface appearing in your app, the SDK’s events, and the webhook chain. How far past that you can go depends on the provider’s sandbox and the payment method.

​
Before you start

Base URL: https://api-sb.meld.io
  • A sandbox API key with payment access
  • Headless onramps enabled on your sandbox account. Ask your Meld representative. Until they are, orders are refused with 403 WHITELABEL_NOT_ENABLED
  • Sandbox credentials for the provider you are testing, on your Meld sandbox account
  • A webhook endpoint reachable from the internet, configured in the dashboard
  • A test customer, KYC-approved: see KYC Testing. Stripe also needs an email on the customer
Sandbox coverage is narrower than production, and a US test customer is the most common reason an otherwise correct integration returns no quotes. Quote first and use whatever country and currency pair comes back with the provider you intend to test. Stripe serves only US customers.

​
Test the card flow

Test cards against Banxa. It is the provider with a published headless card sandbox, and the cards below are its.
  1. Quote for your country, currency pair and amount, and pick the Banxa quote.
  2. Create the order with paymentMethodType: CREDIT_DEBIT_CARD.
  3. Mount the order in your client.
  4. Pay with one of the cards below.

​
Successful authorization

​
Failed and declined authorization

Run at least one decline as well as one success. A decline is the path most integrations get wrong: the surface stays mounted and the customer retries, so nothing should be torn down and no order should be credited.
Other providers’ card sandboxes behave differently and some reject transactions that would succeed in production. Where a provider publishes test cards, they are listed under its section in White-Label API and Meld Checkout testing credentials.

​
Test Apple Pay

Two options in sandbox:
  • Mercuryo or Banxa: you can present the sheet, but not settle a payment. Treat a settled purchase as a production check.
  • Stripe: you can run the whole purchase, with Stripe’s test values, and nothing is charged.

​
Apple Pay with Mercuryo or Banxa

  1. Quote for a country and currency pair that return a Mercuryo or Banxa Apple Pay quote, and pick it.
  2. Create the order with paymentMethodType: APPLE_PAY.
  3. Check canPresentApplePay(), then mount.
The iOS Simulator presents and authorises the sheet but can’t produce a decryptable token, so it exercises mounting, events and the cancel path only. A real device with an Apple sandbox tester account gets a genuine authorisation, and still no settlement.

​
Apple Pay with Stripe

Stripe orders run in an iOS app on Meld’s Stripe sandbox. Card orders run the same way, with paymentMethodType: CREDIT_DEBIT_CARD and no Apple setup. Setup:
  1. Ask your Meld representative to enable Stripe on your sandbox account. It appears under Integrations as Shared Meld Integration, and Meld manages its keys and webhooks.
  2. Send your Meld representative your app’s bundle ID and Apple Team ID, so Stripe registers the app as a trusted application. Stripe’s SDK runs only in a registered app, on a simulator too.
  3. For Apple Pay, register a sandbox merchant identifier, as in Stripe’s certificate.
  4. Build the test app on the iOS SDK or React Native SDK, with the camera permission, configured for sandbox.
  5. Create a KYC-approved test customer with an email, so the SDK fills Stripe’s KYC.
Limits. Stripe’s sandbox caps a purchase at 100 USD, fees included, so quote well under it. It supports only USDC on Ethereum (USDC / ETH), Base (USDC_BASE / BASE) and Solana (USDC_SOLANA / SOLANA), even when a quote lists other pairs. Test values: For document verification, Stripe’s sandbox lets you pick the outcome instead of uploading a document. For Apple Pay, use a physical iPhone with a real card in Wallet: Stripe’s sandbox returns a test token, so the card isn’t charged. Run it:
  1. Quote with integrationMode=HEADLESS, countryCode: US, sourceCurrencyCode: USD and one of the pairs above, including destinationNetworkCode. Pick the STRIPE quote.
  2. Create the order. Expect 201 with responseKind: SDK_BOOTSTRAP.
  3. Mount it from the customer’s tap. Sign in to Link with 000000, and use the test values if Stripe asks for KYC.
  4. Pay. Expect onPaymentSubmitted, or PAYMENT_OUTCOME_UNKNOWN if Stripe hasn’t confirmed yet. Either way, unmount.
  5. Expect TRANSACTION_CRYPTO_PENDING, then TRANSACTION_CRYPTO_TRANSFERRING. That’s a pass: Stripe’s sandbox doesn’t reliably report delivery, so TRANSACTION_CRYPTO_COMPLETE may not arrive.
A refused session ends in TRANSACTION_CRYPTO_FAILED. POST /payments/mock/headless/simulate doesn’t apply to Stripe orders.

​
Verify the result

For card, check all three. Each catches something the others do not. The transaction is created asynchronously, so it will not exist the instant the order call returns. Wait for TRANSACTION_CRYPTO_PENDING.