🇩🇪 Germany · EUR
Cards and Google Pay on the primary acquirer, with automatic failover to the backup.
Demo guide
Scenarios you can run in a minute each.
Each card says what to do in the shop and where the story continues in the Babel backoffice (test mode, Kfold Demoshop merchant). “Load in checkout” fills the cart, market and demo controls for you.
Backoffice links open the Kfold Demoshop workspace, where the rule sets, velocity metrics and provider accounts live. Your Babel login must be a member of it; otherwise the portal stays on Nexora Ventures and those lists look empty. To add someone: switch to Kfold Demoshop (top left), then Admin → Users → Add User, role Customer Admin, test mode.
Markets
🇸🇪 Sweden · SEK
The Sweden checkout variant puts Swish first (simulated Swish and BankID screens).
🇳🇴 Norway · NOK
The Norway checkout variant puts Vipps first (simulated Vipps app).
🇬🇧 United Kingdom · GBP
GBP card payments settle in EUR at the acquirer (FX conversion rule, 1.5% markup).
🇦🇪 United Arab Emirates · USD
USD payments are routed straight to the global (backup) acquirer by a routing rule.
Checkout experience
Approved card payment
The baseline: the shop mints a Babel session server-side and the cashier takes the card in PCI-scoped fields.
- Checkout embedded in the page
- Pay with 4242 4242 4242 4242, any future expiry and CVC
- Tick “Save card” to set up the payout scenario later
Expect: Approved. The order appears in the account history with Babel’s transaction id.
3-D Secure challenge
Strong customer authentication runs inside the cashier. The outcome depends on what the shopper does.
- Hosted page mode (preset): pay with 4000 0000 0000 3220
- Continue to the secure authentication, then click Approve (or Decline / Cancel for the other outcomes)
- Embedded mode opens the challenge in a popup window instead
Expect: Approve → approved. Decline → declined (3ds_auth_failure). Cancel → cancelled (user_aborted_trx).
Issuer declines and recovery
A decline does not end the session: the cashier offers the shopper a retry, and Babel harmonises every provider’s response codes into one stable set.
- Pay with 4000 0000 0000 9995 (insufficient funds)
- The cashier shows “Payment not completed”: click Try again and pay with 4242 4242 4242 4242
- Or click Cancel payment to return to the shop
Expect: Retry → approved in the same session and order. Cancel → the shop shows the cancellation and keeps the cart. The backoffice shows the declined attempt either way.
Sweden: Swish first
One integration, local methods per market: the published design shows Swedish shoppers Swish first.
- Market Sweden (SEK)
- Continue to payment, pick Swish
- In the simulated Swish app, approve (Betala) and sign with BankID
Expect: Approved after the simulated BankID signature. Swish shows the “Sweden · Swish first” variant at work.
Norway: Vipps first
Same shop code, different market: the Norway variant leads with Vipps.
- Market Norway (NOK)
- Pick Vipps, enter any Norwegian mobile number on the Vipps page
- Approve (Betal) in the simulated Vipps app
Expect: Approved. Avbryt in the app shows a shopper cancellation instead.
Google Pay express button
Express wallets sit above the method list. Google’s test environment issues a dummy token, so nothing is charged.
- Use Chrome signed in to a Google account
- Click the Google Pay button at the top of the cashier
- Pick any card in the Google Pay test sheet
Expect: Approved via the google-pay option on the primary acquirer.
Deep link into one method
The shop can pin a session to one method (for a “Pay with Swish” button on the product page, say).
- Demo controls → Pin payment method: Swish
- Continue to payment
Expect: The cashier skips the method list and opens straight into Swish.
Routing and acquirers
Acquirer outage with automatic failover
Acquirer X is down. Babel tries it, fails over to the primary acquirer, and the shopper never notices.
- Demo controls → tick “Simulate acquirer outage”
- Pay with 4242 4242 4242 4242
Expect: Approved. In the backoffice the transaction shows two routing attempts: Acquirer X failed, the primary approved.
Acquirer error cascade
A technical error at the primary acquirer triggers the cascade to the backup acquirer.
- Pay with 4000 0000 0000 0119 (acquirer malfunction)
Expect: Babel retries on the backup acquirer. The simulator fails this card everywhere, so the attempt trail shows both tries.
Route by currency
A routing rule sends USD volume straight to the global acquirer.
- Market United Arab Emirates (USD)
- Pay with 4242 4242 4242 4242
Expect: Approved on the backup (global) acquirer, not the primary.
FX conversion and fees
UK card payments are charged in GBP but settle in EUR at the acquirer, with a markup. Every payment carries its processing fee.
- Market United Kingdom (GBP)
- Pay with 4242 4242 4242 4242
Expect: The transaction shows a GBP amount, an EUR transaction amount and the fee.
Risk and limits
Block list
Fraud rules run before any acquirer is called.
- Email: eve@blocked.test
- Pay with 4242 4242 4242 4242
Expect: Declined with email_block. No acquirer was contacted.
Sanctioned country
Country rules stop payments from markets the merchant cannot serve.
- Billing country: North Korea (sanctions demo)
- Pay with 4242 4242 4242 4242
Expect: Declined with risk_block.
Velocity limit
A velocity metric counts payments per shopper; a fraud rule blocks the fifth within ten minutes (sliding window).
- Load this scenario and pay with 4242 4242 4242 4242, leaving “Save card” unticked
- Repeat “Load in checkout” and pay, four times in total
- Pay a fifth time
Expect: Payments one to four are approved; the fifth is declined with exceeds_frequency before any acquirer is called.
High-value order flagged
Not every rule blocks: a flag lets the payment through and marks it for review.
- Cart: nine Northstar Desk Lamps (over 1,000)
- Pay with 4242 4242 4242 4242
Expect: Approved and flagged for review in the backoffice.
After the sale
Refund from the shop
The shop refunds through the same API; the refund lands in Babel next to the original payment.
- Account → order history → Refund on an approved order
Expect: Refunded. The refund is its own transaction linked to the payment.
Payouts with approval rules
Withdrawals use the same cashier, to a card the shopper saved. Approval rules decide who signs off.
- Account: sign in with the sample shopper
- Run “High-value order flagged” and tick “Save card” in the cashier: the shopper has now paid in over 1,000
- Account → Payouts: 20 (approved automatically), 120 (AI agent pre-screen), 300 (manual review), 600 (four-eyes), 5,000 (denied: more than the shopper paid in)
Expect: Small payouts go straight through; the rest wait in Approvals until someone decides, with the AI agent’s recommendation alongside.
Merchant control
Change the cashier without a release
The shop never changes: the merchant edits, previews and publishes the cashier in the Checkout builder.
- Checkout → Designs → “Kfold Demoshop cashier”: change a colour or the layout, or ask Checkout Genie
- Preview on mobile, publish, then reload the shop checkout
- Roll back to the previous version in one click
Expect: The live cashier changes immediately. Versions, the A/B layout test and the conversion funnel are all in the builder.
Operations: AI analyst, dashboards, monitors, reconciliation
After a few scenarios there is data to explore.
- AI Analyst: “Show approval rate by payment option today” or “Why were payments declined?”
- Dashboards: create one and let the genie build widgets
- Monitoring, Reconciliation and the Audit log
Expect: Answers and charts built from the demo’s own transactions.
Test cards
Bistromathic Lab, Babel's payment simulator. Any future expiry and any CVC. Cards outside this list are decided by the amount, and every shop price ends in .00, which approves.
| Card number | Brand | Outcome | Status code |
|---|---|---|---|
4242 4242 4242 4242 | Visa | Approved, no 3DS | approved |
5555 5555 5555 4444 | Mastercard | Approved, no 3DS | approved |
3782 822463 10005 | Amex | Approved, no 3DS | approved |
4000 0000 0000 3220 | Visa | 3DS challenge: Approve, Decline or Cancel decides | approved · 3ds_auth_failure · user_aborted_trx |
4000 0000 0000 0341 | Visa | 3DS challenge that always fails | 3ds_auth_failure |
4000 0000 0000 9995 | Visa | Declined: insufficient funds | insufficient_funds |
4000 0000 0000 0002 | Visa | Declined: do not honor | do_not_honor |
4000 0000 0000 0069 | Visa | Declined: expired card | expired_card |
4000 0000 0000 0127 | Visa | Declined: invalid CVC | invalid_cvv |
4100 0000 0000 0019 | Visa | Declined: suspected fraud | suspected_fraud |
4000 0000 0000 0119 | Visa | Acquirer malfunction: Babel fails over to the backup acquirer | psp_malfunction |
4000 0000 0000 0051 | Visa | Acquirer timeout: Babel fails over to the backup acquirer | psp_timeout |
Live integration log
Everything the shop server sent to or received from Babel since it started: sessions, status reads, refunds and signature-verified webhooks.