Bistromathic Lab INTERNAL TEST ONLY

Numbers on a restaurant bill obey their own laws of physics; so do payments. The Bistromathic Lab is an internal PSP simulator that mimics a real card processor (auth / debit / capture / refund / void / cancel) so end-to-end tests don't have to depend on Citigate / Circoflow / CC7995.

Not available in production.

HTTP API

• POST /v1/auth — reserve funds (no settlement)
• POST /v1/debit — auth + capture in one step
• POST /v1/capture — capture an existing auth
• POST /v1/refund — refund a captured tx (full or partial)
• POST /v1/void — void an unsettled auth
• POST /v1/cancel — cancel a captured tx
• POST /v1/status — look up a tx by id or merchantRef

All API requests must include the shared secret header X-Sim-Key.

Outcome rules (priority order)

1. Test card match — see table below. An encrypted PAN (ev:…) matches by the card.bin and card.last4 sent beside it.
2. Amount last-2-digits fallback.
3. Default: approved.

Test cards

Amount-last-2-digits fallback

Swish

Swish's Commerce API on Swish's own paths, as its Merchant Integration Guide describes it, so a Swish client can be pointed here instead of at Swish. X-Sim-Key stands in for the client certificate (401, empty body, without it). SEK only; the merchant Swish number is any 123xxxxxxx (Swish's simulator uses 1234679304).

• PUT /swish-cpcapi/api/v2/paymentrequests/{instructionUUID}, POST /swish-cpcapi/api/v1/paymentrequests — 201 with Location, plus PaymentRequestToken when there is no payerAlias (m-commerce)
• GET and PATCH (cancel, application/json-patch+json) /swish-cpcapi/api/v1/paymentrequests/{id}
• PUT /swish-cpcapi/api/v2/refunds/{instructionUUID}, POST /swish-cpcapi/api/v1/refunds, GET /swish-cpcapi/api/v1/refunds/{id} — VALIDATED, DEBITED after 2 s, PAID after 4 s
• POST /qrg-swish/api/v1/commerce — the QR code for a token (format: "svg" only)
• /swish/checkout/{token}?callbackurl=… — the payer: on a computer the merchant's QR page with the phone beside it (scan, Swish, BankID, confirmation); on a phone the Swish app and BankID. &device=mobile|desktop forces either
• /swish/app/{payerAlias} — e-commerce: the payer opening the app to the request waiting for their number

Callbacks POST the payment request or refund as GET returns it, with the callbackIdentifier header when one was given, retried after 5 and 10 seconds until a 200. A payment calls back once it is final; a refund on DEBITED and again on PAID (or ERROR). A request nobody answers ends in ERROR TM01 after three minutes.

Outcomes

In the app, Avbryt declines (DECLINED); Betala hands over to BankID, which signs after two seconds and pays, unless a rule below chose an error; the page's lab drawer cancels in BankID (ERROR BANKIDCL) or lets the request time out. As in Swish's own simulator, a message equal to an error code forces it:

• Refused at create (422): FF08 RP03 BE18 RP01 PA02 AM06 AM02 AM03 RP02 RP06 ACMT03 ACMT01 ACMT07 PA01 (403); for e-commerce also VR01 VR02
• ERROR once the payer signs: RF07 BANKIDCL FF10 TM01 DS24 (and VR01 VR02 for m-commerce)
• Refunds refused at create (422): FF08 RP03 PA02 AM06 RF08 AM03 RP01 RP02 ACMT07 ACMT01 RF02 RF03 RF04 RF06 BE18 PA01 (403)
• Refunds ending in ERROR before DEBITED: RF07 BANKIDCL; after it: FF10 DS24

Otherwise the amount decides (a payment request only):

Vipps

Vipps MobilePay's ePayment API (v1), with its Access Token and Webhooks APIs, on apitest.vipps.no's own paths under /vipps: a Vipps MobilePay client works here by swapping https://apitest.vipps.no for https://<this host>/vipps. The same API answers at the root too (/accesstoken/get, /epayment/v1/…, /webhooks/v1/…). No credentials are checked: any client_id, client_secret and Ocp-Apim-Subscription-Key get a token, and any Bearer token is taken, so a connection's real Vipps keys work unchanged. The Merchant-Serial-Number (five to seven digits) names the sales unit, each its own. A Norwegian sales unit takes NOK only, from 1 kr; an MSN starting 45 or 358 is MobilePay's (see MobilePay).

• POST /vipps/accesstoken/get — a Bearer token for an hour, whatever client_id, client_secret and Ocp-Apim-Subscription-Key are sent (Merchant-Serial-Number names the sales unit). The paths below are under /vipps as well.
• POST /epayment/v1/payments (WEB_REDIRECT or NATIVE_REDIRECT, Idempotency-Key required) — 201 with the landing page as redirectUrl
• GET /epayment/v1/payments/{reference} and …/events
• POST /epayment/v1/payments/{reference}/capture, …/refund (modificationAmount) and …/cancel
• POST /epayment/v1/test/payments/{reference}/approve — the test environment's force approve
• POST, GET /webhooks/v1/webhooks, DELETE /webhooks/v1/webhooks/{id}
• /vipps/landing?token=… — the payer: phone number on a computer (the app at once on a phone), then the Vipps app: pay, cancel, or let it expire

States as at Vipps: CREATED, then AUTHORIZED, ABORTED (the payer cancelled), EXPIRED (ten minutes) or TERMINATED (the merchant cancelled first). An authorized payment stays AUTHORIZED; its aggregate says what was captured, cancelled and refunded. Webhooks are signed with HMAC-SHA256 as Vipps signs them and retried after 2, 4 and 6 seconds until acknowledged. Errors are RFC 7807 problems with Vipps' error codes.

Vipps' test amounts

Lab rules

MobilePay (Denmark, Finland)

MobilePay is Vipps MobilePay's other brand on the same ePayment API as Vipps above: the same paths, keys, states, RFC 7807 errors, force approve and signed webhooks. A sales unit belongs to one market, and every payment it takes must be in that market's currency. Vipps knows a sales unit's market from the merchant agreement; the lab reads it from the MSN, by this convention: the MSN starts with the market's country calling code.

Another currency is refused with 5040 Invalid currency for merchant; less than the minimum with 6010 Amount too small.

• The payer. MobilePay's landing page: the phone number on a computer (+45 or +358), with the phone drawn beside it; the MobilePay app at once on a phone. The app is MobilePay-blue and in Danish or Finnish; Face ID takes two seconds; "Stryg for at betale" / "Pyyhkäise maksaaksesi" pays. ?device=mobile|desktop forces either flow, and the test banner is in Danish or Finnish.
• The card. In Denmark MobilePay pays a business from a card, and the payer picks which one: the card picker opens before they can pay (Visa/Dankort ••1234, Mastercard ••5678, Visa/Dankort ••9012 (its bank's limit: 1.000 kr. per 24 hours)). In Finland the first card is preselected and can be changed (Visa ••1234, Mastercard ••5678).
• Test amounts. Vipps' own test amounts apply in both markets (1,51 insufficient funds … 2,01 unknown for an hour; refunds of 1,23 and 1,24), in kroner or euros. 197 and 202 are 3-D Secure, which Vipps documents as Norway only: in Denmark and Finland they are ordinary amounts. The lab rules from 10 kr. / € 10 apply as for Vipps.
• Deposit-only. The ePayment API refunds but pays nothing out, and Danish and Finnish cashiers pay winnings to a bank account (NemKonto at Danske Spil; at bet365 DK "if you deposited by MobilePay, all withdrawals by bank transfer"). No payer account comes back, so a deposit leaves no payout instrument.

MobilePay's limits

Who takes MobilePay (for a showcase design)

Real or modeled. The API is Vipps MobilePay's real ePayment API, as for Vipps, and so are the per-market currencies and minimums, the Norway-only 3-D Secure amounts and Finland's € 40 000. Modeled by the lab: the MSN convention, the payer's cards and the Danish card limit, running totals kept per sales unit (MobilePay counts across every business), and the Danish and Finnish wording of the screens.

iDEAL

iDEAL 2.0's Merchant/CPSP API (2.0.6) on the iDEAL Hub's own paths, with the acquirer's token endpoint, so an iDEAL 2.0 client can be pointed here instead of at merchant-cpsp-mtls.ext.idealapi.nl. The payer sees iDEAL | Wero's payment page. SIM_API_KEY stands in for every key and certificate iDEAL uses: the client assertion, the acquirer's access token, the request Signature and the Hub's own signatures are HS256 under it (iDEAL signs ES256 with certificates). Any nine-digit merchant id will do, each one its own creditor. EUR only.

• POST /ideal2/merchanttoken — the acquirer: client_credentials with a JWT client assertion (iss = sub = the merchant id, aud = this host); an access token for an hour
• POST /v2/merchant-cpsp/transactions — Request-ID, Authorization: Bearer and a detached-JWS Signature with every https://idealapi.nl/* claim; 201 with iDEAL | Wero's payment page as links.redirectUrl (the bank's own page when issuerId is sent)
• GET /v2/merchant-cpsp/transactions/{transactionId} — the status, and on SUCCESS the debtor and guaranteedAmount
• The transaction-callback on every final status, signed, with Request-ID and X-Sender: iDEAL; iDEAL wants a 204
• /ideal/pay/{token} — the payer: on a computer the QR code (a real phone's camera can scan it) with the payer's phone drawn beside it, or "Kies je bank" for internet banking; on a phone the bank list, then a banking app. ?device=mobile|desktop forces either

Statuses as at iDEAL: OPEN, IDENTIFIED (the code was scanned or a bank chosen), then SUCCESS, CANCELLED, FAILURE or EXPIRED (after expirationPeriod, 1200 seconds by default). Errors are iDEAL's {code, message, traceId}. iDEAL has no refunds. The banks offered: ABN AMRO, ASN Bank, bunq, Finom, Handelsbanken, ING, Knab, N26, Nationale-Nederlanden, Rabobank, RegioBank, Revolut, SNS, Triodos Bank, Van Lanschot Kempen, Yoursafe; their screens are a plain banking app, no bank's design.

iDEAL's test amounts

Lab rules

BLIK (PayU)

BLIK, Poland's bank-app payment, on PayU's REST API v2.1, on PayU's own paths under /payu: a PayU client swaps https://secure.snd.payu.com (or https://secure.payu.com) for https://<this host>/payu and changes nothing else. PLN only. Each merchantPosId is a POS of its own (PayU's public sandbox POS is 300746).

Credentials are ignored. The OAuth endpoint gives a token to any client_id / client_secret, and no call is refused for its bearer token. What PayU signs, the lab signs PayU's way: notifications carry OpenPayu-Signature: sender=checkout;signature=<MD5(body + second key)>;algorithm=MD5;content=DOCUMENT with the published simulation key bistromathic-lab-simulated-flow as the second key.

• POST /payu/pl/standard/user/oauth/authorize — client_credentials (and trusted_merchant), form-encoded; a bearer token for 43199 s
• POST /payu/api/v2_1/orders — payMethods.payMethod {type:"PBL", value:"blik"}: 302 with redirectUri (PayU's BLIK page) in the body and Location; {type:"BLIK_AUTHORIZATION_CODE", value:"<6 digits>"}: 201, the order PENDING while the payer confirms (a refused code: 400 ERROR_AUTHORIZATION_CODE with the order's id); {type:"BLIK_TOKEN"} for a One Click token
• GET / DELETE /payu/api/v2_1/orders/{orderId}, GET …/transactions (each BLIK attempt and its resultCode)
• PUT …/status (orderStatus: COMPLETED) and POST …/captures — receive an order WAITING_FOR_CONFIRMATION
• POST / GET …/refunds, GET …/refunds/{refundId} — PENDING, FINALIZED three seconds later (or CANCELED); PayU's 9101–9115 refusals
• GET /payu/api/v2_1/paymethods — with a trusted_merchant token, the buyer's One Click tokens
• Notifications to notifyUrl on PENDING, WAITING_FOR_CONFIRMATION, COMPLETED and CANCELED, and on a refund's FINALIZED / CANCELED; PayU wants an HTTP 200
• /payu/pay?orderId=…&token=… — the payer: PayU's BLIK page; on a computer with the payer's phone beside it (the BLIK tile, the code with its two-minute countdown, the push with Zatwierdź / Odrzuć, the PIN for two seconds); on a phone the page alone and the banking app at /payu/bank. &device=mobile|desktop forces either
• /payu/bank?pos=300746 — the payer's banking app on its own: its codes work for a merchant that sends BLIK_AUTHORIZATION_CODE, and the push appears there

Statuses as at PayU: NEW, PENDING (the code is in, the payer confirms in the app), WAITING_FOR_CONFIRMATION (a POS without auto-receive), COMPLETED, CANCELED. A code is valid two minutes and once; the payer has a minute to confirm (BLIK publishes no figure). A NEW order is CANCELED when its validityTime (86400 s by default) runs out. On the payment page a refused code leaves the order NEW for another try; "Anuluj płatność" cancels it and returns to continueUrl with error=501, as does any failure.

PayU's BLIK test codes

A code from the lab's banking app is a real one: valid two minutes, once (AUTH_CODE_EXPIRED, AUTH_CODE_USED), refused over the payer's bank limit (AUTH_CODE_LIMIT_EXCEEDED), and confirmed or rejected by the payer in the app. Six digits nobody issued: AUTH_CODE_INVALID.

Tpay's failure amounts, as lab rules (exact amounts)

Lab rules

Limits

BLIK has no scheme limit; each bank sets its own. The payer's phone can belong to any of these banks (the lab drawer switches), each with its default daily limit for BLIK payments online, summed per Warsaw day:

A single payment above 999 999,99 zł is refused (ERROR_VALUE_INVALID): PayU publishes no BLIK maximum, this is the largest a Polish BLIK PSP publishes. Merchants cap lower themselves: Totalbet takes 1–1 000 zł per BLIK deposit, which is the cashier's rule, not PayU's. BLIK is deposit-only: refunds go back to the account the payment came from, and BLIK reports no IBAN.

PayU's status codes

Real vs modeled. Real: the paths, OAuth, the order and refund shapes, statuses and status codes, the 302 with redirectUri, the refund error codes, the notification and its MD5 signature, BLIK's test codes. Modeled: PayU's tokens are opaque ids it keeps (the lab's carry the POS and grant in the open); the HTTP status of a refused BLIK code (400); AUTH_CODE_LIMIT_EXCEEDED read as "over the payer's bank limit"; the resultCode literals AUT_ERROR_USER_REJECTED, AUT_ERROR_TIMEOUT and AUT_ERROR_SECURITY (PayU's own are AUT_ERROR_NO_AUTHORIZATION, _LIMIT_EXCEEDED, _INSUFFICIENT_FUNDS); the refusal of a DELETE on a COMPLETED order; the order id's first ten characters, which carry the POS; the payment page and the banking app (redrawn, a generic bank). Notifications are tried twice, 5 s apart (PayU retries for 72 hours).

Redsys (Bizum)

Redsys' TPV Virtual, on the real hosts' own paths under /redsys: a client of https://sis-t.redsys.es:25443 (test) or https://sis.redsys.es (production) is pointed at <lab>/redsys instead. Bizum only (Ds_Merchant_PayMethods z), euros only, sold in one step (Ds_Merchant_TransactionType 0). Any merchant code (FUC) is a merchant of its own; Redsys' public test merchant is 999008881, terminal 1.

Credentials are ignored: no request is refused for its Ds_Signature. What Redsys signs — the online notification, the Ds_* parameters on the way back to URLOK/URLKO, the REST answers and the query answers — the lab signs Redsys' way (HMAC_SHA256_V1: a per-order key, 3DES-CBC of Ds_Order under the secret key, then HMAC-SHA256 of the Base64 parameters) with the simulation key YmlzdHJvbWF0aGljLWxhYi1zaW11bGF0: Base64 of the first 24 bytes of the lab's published simulation secret bistromathic-lab-simulated-flow. A connection's "Simulated flow" uses it as its secret key.

• POST /redsys/sis/realizarPago — the redirection: the payer's browser posts Ds_SignatureVersion, Ds_MerchantParameters (Base64 JSON: DS_MERCHANT_AMOUNT, _ORDER, _MERCHANTCODE, _TERMINAL, _CURRENCY 978, _TRANSACTIONTYPE 0, _PAYMETHODS z, _MERCHANTURL, _URLOK, _URLKO, _MERCHANTDATA…) and Ds_Signature; Redsys' Bizum page opens. Refusals show Redsys' error page with the SIS0xxx code in its source (SIS0051 for an order used before; the same form posted again resumes it)
• POST /redsys/sis/rest/trataPeticionREST — the triplet as JSON; refunds (DS_MERCHANT_TRANSACTIONTYPE 3, the payment's own order) answer the signed triplet with Ds_Response 0900, or {"errorCode":"SIS0xxx"}
• POST /redsys/apl02/services/SerClsWSConsulta — the SOAP query service (SOAPAction: consultaOperaciones): Transaction, Monitor and Detail by order, answered with Ds_State and Ds_Response per operation, signed; XML0024 for an order Redsys never saw
• /redsys/bizum/{token} — the payer (lab paths): Redsys' page with the phone number (+34), then Request to Pay (the bank app's push and a 4-minute countdown) or the legacy Clave Bizum and SMS code; on a computer the payer's phone is drawn beside it. ?device=mobile|desktop forces either; POST /redsys/sis/realizarPago?device=… too

The online notification is a form POST of the signed triplet to DS_MERCHANT_MERCHANTURL on every final state (Redsys takes any HTTP 200), retried once after five seconds; refunds notify too when they name a MerchantURL. URLOK (authorised) or URLKO (anything else) gets the same signed triplet as query parameters. The query service reports Ds_State S (page open), P (with the payer's bank), F (final) or T with 9998 (sin finalizar: the payer's time ran out — four minutes once the push is sent, 10 minutes on the page or in Clave Bizum).

Payers

Clave Bizum: any four to eight characters (1234 in Redsys' sandbox). SMS code: 123456; 3 wrong codes deny with 0184. The bank app's "Rechazar" and Redsys' "Cancelar" end with 9915.

Bank limits (e-commerce, as published)

Beyond a limit the bank says no and Redsys reports 9966 (Bizum's KO); the bank app says which limit. Bizum's €1,000 per operation is its person-to-person limit, not e-commerce: shops are capped by the payer's bank. Other banks publish no e-commerce limit and the lab enforces none.

Lab rules

Refunds

Within 365 days, partial or full, up to 10 % over the payment in total (Bizum lets a refund exceed the original by the acquirer's percentage); beyond that SIS0057. A refund whose amount ends in 85 cents is refused by Bizum (9485). Bizum pays nothing out to a payer otherwise: it is deposit-only.

Ds_Response

Real or modeled

• Real (Redsys' manuals): the paths, the triplet, the HMAC_SHA256_V1 signature, the request and notification fields, Ds_Response values, the SIS and XML error codes, the SOAP query service, R2P's four minutes and 9998 "sin finalizar".
• Real but secondary: 9966/9485/9677 as Bizum's codes (Monei's list of Redsys codes), Paylands' sandbox numbers and push bands, the Clave Bizum/SMS sandbox values (DEUNA), BBVA's and CaixaBank's limits (eurosport.es).
• Modeled: Redsys' page and its steps (the lab's own drawing), the payer paths, the ten-minute session, the receipt continuing by itself, Ds_ProcessedPayMethod 68, DS_MERCHANT_BIZUM_MOBILENUMBER prefilling the phone, a notification for a refund, the SOAP envelope's exact namespaces, the 10 % refund allowance and the lab rules. Bizum's REST push (R2P without redirection) is not simulated (SIS0112).

Brite (Instant Payouts)

Brite's merchant API, the payout half, on Brite's own paths under /brite: a Brite client works here by swapping https://sandbox.britepaymentgroup.com (or https://production.britepaymentgroup.com) for https://<this host>/brite. It is the bank rail BabelPay pays withdrawals out on when the deposit method cannot receive money (iDEAL, MobilePay, BLIK, Bizum…): a pay-by-bank credit to the player's IBAN. No credentials are checked: any public_key and secret get a token, and the token names the merchant (its public key), each with its own accounts and payouts. Brite deposits (the Brite Client) are not simulated.

• POST /brite/api/merchant.authorize (public_key, secret) — access_token, expires (six hours), refresh_token; merchant.token renews them. Every other call wants Authorization: Bearer … (401 without one); a token the lab did not issue is taken, for one shared merchant
• POST /brite/api/bank_account.create (country_id, iban, holder_firstname, holder_lastname, holder_dob, holder_address) — {id}; the same IBAN again updates the holder and keeps the id. bank_account.get shows it masked
• POST /brite/api/transaction.create_withdrawal (amount, bank_account_id, currency_id, merchant_reference, statement_reference, brand_name, callbacks) — {id, eta}. The same merchant_reference with the same amount answers the first payout again; with another amount it is refused
• POST /brite/api/transaction.get, transaction.get_by_merchant_reference, transaction.state
• POST /brite/api/country.list, currency.list
• POST /brite/api/lab.set_returned_funds_url (url) — lab only: Brite keeps the returned-funds notification URL in its Back Office; here a merchant sets it with this call

A payout is PENDING (1) at once, then COMPLETED (4), CREDIT (5) and SETTLED (6) a second apart. Callbacks POST {merchant_id, transaction_id, transaction_state} with User-Agent: Brite Callback to each URL subscribed to a state the payout reaches (2, 3, 4, 5 or 6), unsigned, as Brite's are: the merchant reads the payout back with transaction.get. ABORTED (2) carries an error_code; FAILED (3) none. When a settled payout's money comes back, a Returned Funds transaction (type 13, related_transaction_id = the payout) appears and {merchant_id, transaction_id, original_transaction_id, notification_type: "RETURNED_TRANSACTION", country_id, amount} goes to the returned-funds URL.

Checked as Brite checks: amount a number of at least 1.0 with at most two decimals (Brite's own error text); the bank account must exist; currency_id (CHF, DKK, EUR, GBP, HUF, NOK, RON, SEK, Brite's list: no PLN) must be the account's currency; statement_reference is refused for Swedish and Finnish accounts and over 105 characters; callbacks only for states 2–6. Errors are Brite's: HTTP 400 {error_name, error_message, state: "APPLICATION_ERROR"} (TransactionInvalid, NotFound, InvalidRequest, NotAvailable, BadRequest). A bank account takes a valid IBAN (mod 97) in its country_id, one of: AT, BE, CH, DE, DK, EE, ES, FI, FR, GB, HR, HU, IE, IT, LT, LU, LV, NL, NO, PT, RO, SE, SI, SK.

Brite's sandbox amounts

Lab rules

Real or modeled. Brite's: the paths, the token exchange, the request and response fields, the transaction states and their order, callback bodies, returned-funds notifications, the merchant_reference idempotency, the statement_reference rules, the currency list, the error body and the amount error's text, and the sandbox amounts 11.01–14.01. Modeled by the lab: which error code 11.01 and 11.02 carry, the other error texts, a second between states, the list of payout countries, the IBAN and age rules, the 401, the low-balance and slow-pending amounts, the bank name (Brite's sandbox "Test Bank"), and the Back Office setting as an API call. Callbacks are tried twice (now and after five seconds); Brite retries after 10, 30 and 60 minutes.

Paysafe: paysafecard, Skrill, Neteller, Play+, VIP Preferred, SafetyPay

The Paysafe Payments API (paymenthub v1) on the real host's paths, under /paysafe: a client of https://api.test.paysafe.com (or https://api.paysafe.com) reaches the lab at https://<lab>/paysafe and changes nothing else. One engine for every brand (paymentType PAYSAFECARD, SKRILL, NETELLER; the US gaming rails and SafetyPay Express below). Credentials are ignored: any HTTP Basic API key is taken; its username only names the merchant, each username a merchant of its own (no credentials: lab-merchant).

• POST /paysafe/paymenthub/v1/paymenthandles — transactionType PAYMENT (INITIATED, action: REDIRECT, a redirect_payment link valid 15 minutes), STANDALONE_CREDIT or VERIFICATION (PAYABLE at once, action: NONE); GET …/paymenthandles/{id}, GET …/paymenthandles?merchantRefNum=
• POST /paysafe/paymenthub/v1/payments with a PAYABLE handle's paymentHandleToken — COMPLETED; GET …/payments/{id}, ?merchantRefNum=; POST …/payments/{id}/settlements (paysafecard with settleWithAuth: false)
• POST /paysafe/paymenthub/v1/settlements/{id}/refunds — PENDING, then COMPLETED after 3 s (a payment settled with auth is its own settlement); GET …/refunds/{id}
• POST /paysafe/paymenthub/v1/standalonecredits — a withdrawal with a STANDALONE_CREDIT handle's token; GET …/standalonecredits/{id}
• POST /paysafe/paymenthub/v1/verifications — Neteller/Skrill account check: MATCH / NO_MATCH per field and verificationLevel 00/01/10/11
• GET /paysafe/paymenthub/v1/balances?paymentType=&currencyCode=
• /paysafe-lab/pay/{token} — the payer: paysafecard's panel (a PIN tab, 4×4 boxes, up to 10 PINs, and a my paysafecard tab), Skrill's and Neteller's login, 2-step verification and review; on a computer the phone with the brand's app beside the page, on a phone full-screen. ?device=mobile|desktop forces either
• /paysafe-lab/portal?merchant={username} — the stand-in for the Business Portal, where Paysafe merchants subscribe webhooks (Paysafe has no API for it): a page, and JSON at GET|PUT|PATCH /paysafe-lab/portal/settings ({mcc, businessName, webhooks:[{url, events?}]}; PATCH takes addWebhook / removeWebhook). The merchant is the Basic username or ?merchant=. MCC 7995 (the default) is a gambling merchant

Webhooks, as Paysafe sends them: the envelope {payload, eventType, eventName, attemptNumber, resourceId, eventDate, links, mode}, signed in a Signature header = Base64(HMAC-SHA256(key, raw body)). The key is the published simulation key bistromathic-lab-simulated-flow (a real merchant's is its Business Portal HMAC key). Events: PAYMENT_HANDLE_PAYABLE / _FAILED / _EXPIRED / _COMPLETED, PAYMENT_COMPLETED / _FAILED, SETTLEMENT_COMPLETED, REFUND_COMPLETED / _FAILED, SA_CREDIT_PENDING / _COMPLETED / _FAILED; each to every subscribed URL.

Magic values

• paysafecard's published test PIN 7740228278243675 holds 1,000.00. Lab PINs: six zeros, then the value in cents (0000 0000 0000 2500 holds 25.00; all zeros is used up). 9999 9999 9999 9999 is blocked. Any other PIN is invalid. Up to 10 PINs combine; balances are not used up.
• Accounts, any password (any other email logs in as a fresh verified account holding 1,000.00, in the name the merchant's profile gives):

  Brand	Email	Holder	What it shows
  PAYSAFECARD	psc.at@example.com	Anna Huber, 1990-04-12, AT	Austria, fully verified
  PAYSAFECARD	psc.de@example.com	Lukas Schmidt, 1985-09-30, DE	Germany, fully verified, confirms in the my paysafecard app; payouts €30,000 a year
  PAYSAFECARD	psc.uk@example.com	Oliver Smith, 1992-02-17, GB	UK Standard: payouts £250 a month
  PAYSAFECARD	psc.simple@example.com	Mia Weber, 1995-07-01, AT	simple KYC only: refused where the merchant asks for FULL
  PAYSAFECARD	psc.minor@example.com	Jonas Bauer, 2010-05-05, AT	16 years old, unverified: refused by an age or KYC restriction
  SKRILL	skrill.player@example.com	Maria Rossi, 1988-03-22, IT	verified
  SKRILL	skrill.uk@example.com	James Brown, 1979-11-08, GB	verified, UK
  SKRILL	skrill.unverified@example.com	Sofia Garcia, 1999-12-01, ES	unverified: pays at most €250
  SKRILL	skrill.blocked@example.com	Tomas Novak, 1983-06-14, CZ	gambling block on: no payments to gambling merchants (payouts still arrive)
  NETELLER	neteller.player@example.com	Erik Larsen, 1986-01-30, NO	verified, with a verified card (level 11)
  NETELLER	neteller.uk@example.com	Emily Clarke, 1991-08-19, GB	verified, no verified instrument (level 10)
  NETELLER	neteller.unverified@example.com	Piotr Kowalski, 1997-04-03, PL	unverified (level 00): pays at most €250
  NETELLER	neteller.negative@example.com	Victor Lazlo, 1975-10-10, DE	in Paysafe's negative database: payments and payouts refused (4001)

• Skrill and Neteller always ask for the second factor; approve on the phone, or type the six digits the app shows.

Limits, enforced with Paysafe's errors

• paysafecard: €1,000 (or the equivalent) per transaction — the handle create answers 502 1001 with 4003 in details.
• paysafecard PIN payments: €50 in Germany, £40 in the United Kingdom, by the billing country (the panel refuses; pay with an account instead).
• paysafecard: a kycLevelRestriction or minAgeRestriction, or a payer in Germany at a gambling merchant, takes accounts only (Germany since October 2020; Entain everywhere since September 2021).
• my paysafecard payouts: name and date of birth must match the account (3195; no account 3162), only in Paysafe's 29 payout countries; Germany €30,000 a year, UK Standard £250 a month (Unlimited £24,000 a year), as running totals.
• Skrill refunds are refused to gambling merchants (3419): pay the player with a standalone credit. paysafecard refunds are full only (3418); a PIN payment's refund needs customerAccountId.
• Unverified Skrill and Neteller wallets pay at most €250 (modeled). Skrill's gambling block stops payments to gambling merchants; payouts still arrive.

Lab rules

Real vs modeled. Real (developer.paysafe.com): the paths, the payment-handle → payment flow, statuses, the 15-minute handle, the field names, the webhook envelope and signature, Paysafe's error codes and body {error:{code, message, details, fieldErrors}}, paysafecard's test PIN, caps and payout rules, Skrill's refund rule, Neteller's verification levels. Modeled: which paymenthub code carries a paysafecard gateway refusal (1001, with the gateway's code in details), PENDING refunds settling after 3 s, the unverified-wallet cap, the personas, the PINs, the lab rules, the /monitor check, and the Business Portal stand-in. Rapid Transfer and Skrill 1-Tap are not simulated.

Play+ and VIP Preferred (US gaming rails)

The same API, paymentType SIGHTLINE (Play+) and VIPPREFERRED (VIP Preferred eCheck, Pavilion Payments), USD only. A deposit is a PAYMENT handle with action: REDIRECT to the method's hosted page, PAYABLE once the payer confirms, then /payments. A withdrawal is a STANDALONE_CREDIT handle, PAYABLE at once, then /standalonecredits.

• Play+: sightline: {consumerId}, the merchant's Loyalty Membership Number for the player (and optionally ssn, served back as last4ssn). The payer signs in to Play+ (any password), types the code Play+ texts to the phone drawn beside the page, and confirms. A Play+ account is enrolled under the consumerId by its first deposit; a payout to a consumerId never seen answers 1001 IM (Invalid Member Number). Refunds work as for the wallets.
• VIP Preferred: vippreferred: {consumerId} is the player's Social Security number (nine digits, served back as its last four only); profile (firstName, lastName, email, phone) and billingDetails (country, zip) are required. The payer confirms their date of birth and the SSN's last four, picks a registered bank account or links one (sign in to online banking with any username and password, then the code the bank texts), and authorises the eCheck. The payment echoes the bank account with its bank token (vippreferred.achBankAccounts[].paymentHandleToken); a payout names it as vippreferred.paymentHandleToken. POST …/verifications with a VERIFICATION handle lists a player's accounts. No refunds (3419): pay back with a standalone credit.
• Play+ accounts (any password): playplus.player@example.com (New Jersey, $2,500 on the account, a linked bank tops up a short balance); playplus.low@example.com (Pennsylvania, $25 on the account and no linked bank: more is refused on the confirm page); playplus.suspended@example.com (account suspended: the payment fails (4001)); any other email is a fresh account holding $1,000.00.

Limits (modeled; Paysafe's pages give none): Play+ $10,000 per deposit, VIP Preferred $5,000 per eCheck, refused with 3027. Gambling cashiers offer both in the states with regulated online casino gaming (NJ, PA, MI, WV, DE, CT, RI) and for sports betting in more; the lab leaves the state to the operator's geolocation.

SafetyPay Express (LatAm bank transfer and cash)

paymentType ONLINE_BANK_TRANSFER with paymentDetails: {countryCode, bankNameCodes?}, or SAFETYPAY_CASH with safetypayCash: {countryCode, bankNameCodes?}; profile.email required; paymentExpiryMinutes (default 15). Amounts are in Paysafe's two-decimal minor units, CLP and COP included (CLP 123 is 12300). The handle is PAYABLE once the payer has picked a bank or cash point and has a payment code (the handle's gatewayResponse.operationId); /payments then answers PROCESSING until the code is paid (PAYMENT_COMPLETED webhook), COMPLETED when it already is, and the payment FAILS when the code expires unpaid (1001 with PAYMENT_EXPIRED in details, modeled). A PAYABLE handle nobody uses is paid by Paysafe itself when it expires: PAYMENT_HANDLE_EXPIRED with statusReason: AUTO_SETTLE_EXPIRED_PAYMENT_HANDLE, then the payment. Payments only: no refunds (3419), no standalone credits (5040).

• Online banks:
  • BR, BRL: ITAU (BRL up to 57,000), SANTANDER (BRL up to 57,000), BANCO_DO_BRASIL (BRL up to 57,000), BRADESCO (BRL up to 57,000)
  • CL, CLP: BANCO_ESTADO (CLP up to 8,500,000), BANCO_BCI (CLP up to 500,000), SCOTIABANK_CHILE (CLP up to 8,500,000)
  • CO, COP: ONLINE_BANK_PAYMENT_BANCOLOMBIA_COLOMBIA (COP 1–40,000,000), BBVA_COLOMBIA (COP 1–40,000,000), BANCO_DE_BOGOTA (COP 1–40,000,000), BANCO_DAVIVIENDA (COP 1–40,000,000), NEQUI_COLOMBIA (COP 1–40,000,000), BANCO_CAJA_SOCIAL (COP 10,000–40,000,000)
  • CR, CRC: BANCO_NACIONAL_DE_COSTA_RICA (CRC up to 6,200,000)
  • PE, PEN: BANCO_DE_CREDITO (PEN up to 43,000), BBVA_CONTINENTAL (PEN up to 43,000), INTERBANK (PEN up to 43,000), SCOTIABANK (PEN up to 43,000), BCP_CUOTEALO (PEN up to 7,000)
• Cash points:
  • BR, BRL: LOTERICAS (BRL up to 57,000), BRADESCO (BRL up to 5,000)
  • CL, CLP: BANCO_ESTADO (CLP up to 8,500,000), CAJA_VECINA (CLP up to 8,500,000), WALMART_CHILE (CLP up to 3,000,000), LIDER (CLP up to 3,000,000)
  • CO, COP: EFECTY (COP up to 6,000,000), SURED (COP up to 4,000,000), GANA (COP up to 4,000,000), PUNTO_RED (COP up to 800,000)
  • CR, CRC: BANCO_NACIONAL_DE_COSTA_RICA (CRC 637–6,200,000)
  • PE, PEN: BANCO_DE_CREDITO (PEN up to 1,000), BBVA_CONTINENTAL (PEN up to 1,900), INTERBANK (PEN up to 700), WESTERN_UNION (PEN up to 43,000), TAMBO (PEN 1–500), KASNET (PEN 1–1,000)
• At the bank, any username and password; a cash code is paid at /paysafe-lab/pay/{token}/cashdesk (the lab's cash desk), linked from the code page and the drawer.
• SafetyPay's refusals, with its own code in details: 5010 21519 no country, 5068 21505 unknown country, 5001 21513 currency not of the country, 5068 21526 bank not in the country, 5003 10105 amount outside every offered bank's limits, 5068 21653 invalid profile.email.

Real vs modeled. Real (Paysafe's Play+, VIP Preferred and SafetyPay Express pages and its OpenAPI file): the payment types, the brand objects, the redirect → PAYABLE → payment and standalone-credit sequences, VIP Preferred's bank accounts, bank tokens and Verification API, SafetyPay's countries, currencies, bank codes and limits, its PROCESSING payments, auto-settle and error pairs. Modeled: every payer page (Paysafe hosts them and documents none), the Play+ and VIP Preferred caps, the personas, the SMS codes, the expired-code error and the cash desk.

Trustly

Trustly's JSON-RPC 1.1 API on test.trustly.com's own path, under /trustly: a Trustly client swaps https://test.trustly.com for this host's /trustly. Credentials are ignored: any Username, Password and request Signature will do. The Username names the merchant: each one has its own orders, ledger and balance (1 000 000.00 in each currency to start). Answers and notifications are signed the Trustly way (SHA1withRSA over method + UUID + Trustly's serialisation of data, Base64) with the lab's published test key in place of Trustly's: its public key is in bistromathic-lab/src/trustly/trustly-simulation-keys.ts, and a connector trusts it only in its simulated flow. SEK, EUR, DKK, NOK, PLN, GBP and CZK.

• POST /trustly/api/1: Deposit (Pay N Play with RequestKYC: "1"), Refund, AccountPayout, Withdraw, ApproveWithdrawal, DenyWithdrawal, GetWithdrawals (payouts, withdrawals, and a deposit's refunds), Balance, AccountLedger
• /trustly/checkout?OrderID=…&SessionID=… — the payer: country and bank, the bank's login (SE Mobile BankID with a real QR code; EE/LV/LT Smart-ID; DE login and pushTAN; elsewhere the bank's app), the account with its balance, confirm, sign, and back to SuccessURL / FailURL. On a computer the payer's phone is drawn beside the page; ?device=mobile|desktop forces either flow.

Notifications go to NotificationURL as Trustly sends them: account (when the payer picks an account: accountid, verified, clearinghouse, bank, descriptor, lastdigits, name; with KYC also personid, address, zipcode, city), kyc (Pay N Play, sent while the payer waits: an answer with "status": "FINISH" aborts), pending (signed), credit (2 s later), cancel, debit (a deposit taken back), payoutconfirmation (3 s after an AccountPayout; a credit if the money comes back). Trustly's HoldNotifications: "1" holds them for the lab drawer's notification tool. An order nobody finishes is cancelled after 30 minutes. Refunds answer at once (a pending deposit's refund is queued until the credit) and send nothing. Each notification is tried twice; Trustly wants its signed {"status": "OK"} back, and the lab logs any other 2xx.

Test cases ("Set order options", in the lab drawer)

Trustly's test checkout names these cases; what each does here is the lab's reading of it.

Lab rules (when no test case is set)

Markets, banks and limits

Trustly has no fixed limit: the payer's bank decides. One payment over the bank's limit (below, in the market's currency) is refused at signing (cancel). * from a third-party table (unverified); the rest are the lab's. A deposit an account cannot cover greys that account out. The payers are invented, one per market (Sweden also has a 16-year-old, for Pay N Play's age check).

Errors

CircoFlows (Circoflow)

CircoFlows' card gateway on the real host's paths, under /circoflow: a client of https://gateway.circoflows.com/api/v1/test (sandbox) or …/api/v1 (production) reaches the lab at https://<lab>/circoflow/api/v1/test or …/circoflow/api/v1 and changes nothing else. JSON, snake_case, amounts as decimal strings, lowercase statuses. Credentials are ignored: any Authorization: Bearer key is taken and only names the merchant (no key: lab-merchant); sandbox and production keep separate books.

• POST /circoflow/api/v1[/test]/payment/create — customer, billing address, amount, currency, merchant_transaction_id, card, return_url, webhook_url, every one required. Answers {status, reason, merchant_transaction_id, transaction_id[, 3ds_url]}: success, processing with a 3ds_url, pending, or a refusal (declined / blocked, nothing filed). Validation failures are Circoflow's Laravel messages on a declined status ("The phone field is required."); a card number failing Luhn is HTTP 400 "Invalid card number."
• POST /circoflow/api/v1[/test]/payment/status {merchant_transaction_id} — {success: true, data: {transaction_id, merchant_transaction_id, status, amount, currency, message, customer_info, payment_info, created_at, processed_at}}, or 404 {success: false, error: "Transaction not found."} (also for a refused create-payment, and for __test_connection__)
• GET /circoflow/3ds/authenticate/{token} — the hosted 3-D Secure page: the card issuer's challenge. Confirmed, the payer goes back to return_url (a GET, nothing in the URL) and the payment is pending ("Payment pending.") for 3 s, then success. Failed: declined "3ds_rejected"; cancelled: declined "Payment attempt failed or cancelled"; opened and unanswered 10 minutes: declined "3ds_timeout". Never opened, it stays processing.
• Webhooks: every final outcome of a filed payment is POSTed to webhook_url as {event: "payment.notify", data: {…}}, unsigned (Circoflow signs nothing; BabelPay reads the payment back).

Test cards (the lab's own; any future expiry, any CVV)

An encrypted card (ev:…) is recognised by the BIN and last four BabelPay sends in X-Bistromathic-Card-Bin / -Last4.

Lab rules: the amount's last two digits (minor units), any other card

Any other amount is approved. Also: an expiry in the past is declined "Card expired."; an expiry year after 2050, an empty field or a malformed one is a validation message; a merchant_transaction_id used before is declined "Duplicate merchant_transaction_id not allowed".

Real vs modeled. CircoFlows publishes no API document; the API is reverse-documented from BabelPay's integration and the answers it has seen. Real (as observed): the two endpoints, the field names, amounts as strings, the statuses and their casing, the sandbox's and production's reason strings (including the acquirer's pipe frame and the "Issuer Decline-" prefix), blocked, "Transaction not found." for a refused payment, asynchronous settlement after 3DS, a never-opened 3DS page never expiring, the unsigned payment.notify webhook, created_at without a zone. Modeled: which card or amount gives which outcome, the HTTP statuses of validation answers, the exact wording of validation messages other than the observed ones, the 3 s and 5 s settlement delays, the 10-minute challenge timeout, a webhook for a payment approved at create, the masked payment_info, and the velocity block (answered by magic values, not by counting declines). Circoflow offers no refund, capture or void to BabelPay, so the lab serves none.

CC7995 (cards)

The CC7995 API (the bundled CC7995 API.pdf, the only reference) on the real host's paths, under /cc7995: a client of https://api.7995-endpoint-b.com reaches the lab at https://<lab>/cc7995 and changes nothing else. Credentials are ignored: X-Api-ClientId only names the calling system (each its own payments; none: lab-client), X-Api-Signature is never checked; an X-Api-RequestDate more than ten minutes off is refused with 6, as CC7995 does. A card arrives as vault ciphertext on a simulated BabelPay connection (no Evervault relay in front of the lab); the lab knows its test cards by BabelPay's X-Bistromathic-Card-Bin / -Last4 hint.

• POST /cc7995/api/v2/payments — create payment (§5.1.1): user_id, amount (major units, a JSON number), currency, success_url, fail_url, timeout (minutes, default 60), additional_data (≤ 100), beneficiary_url, … → {data:{payment_url, payment_id, user_id}}, the payment NEW; payment_url is the method web form
• POST /cc7995/api/v2/payments/card — host-to-host bankcard payment (§5.1.2): payment_id, card_number, validity_month 1–12, validity_year 22–99, verification_code, cardholder_name (Latin, two words), payer_email, display_language → {data:{payment_url, …}}, the payment confirmation page. A second card on one payment: 203
• GET /cc7995/api/v2/payments?payment_ids=<id1>,<id2>… — status (§5.1.3), at most 20 ids, newest first; an unknown id is left out → {data:[…], total, response_date}
• /cc7995-lab/confirm/{token} — the payment confirmation page: Pay (two seconds), then the issuer's 3-D Secure challenge for a card that asks for one (the lab's shared issuer page), or Cancel payment; then back to success_url (COMPLETED) or fail_url (DECLINED). ?device=mobile|desktop forces either layout
• /cc7995-lab/pay/{token} — the method web form (a bank card form), which BabelPay never shows
• /cc7995-lab/admin?client_id={ClientId} — the stand-in for the platform administration, where a calling system's PaymentCallbackUrl is registered (CC7995 has no API for it): a page, and JSON at GET|PUT|PATCH /cc7995-lab/admin/settings ({paymentCallbackUrl, merchantName}; the ClientId is X-Api-ClientId or ?client_id=). A simulated BabelPay connection registers its own

Postbacks (§6), as CC7995 sends them: POST JSON {data:{…the status item…}} to the PaymentCallbackUrl, with X-Signature = lower-case hex SHA-512(ClientId + body + ClientSecret); the ClientSecret is the published simulation secret bistromathic-lab-simulated-flow, the ClientId the payment's own. Delivered on HTTP 200; sent when a payment is decided (COMPLETED or DECLINED).

Test cards (the lab's: CC7995 publishes none)

Any future expiry, any CVV, a cardholder name of two Latin words.

Lab rules, for any other card

• Amount 0 or less, with more than two decimals, or over 25,000: 212 at create payment. Any currency of three letters is taken (CC7995's sandbox channel is EUR only).
• Card checks at the card payment: Luhn 204, expiry format or in the past 205, CVV 3–4 digits 206, cardholder name 207, email 208, any brand but Visa or Mastercard 209 (answered in the gateway's observed shape: the code as a string under code and error_code, the text under error, error_message and errors).
• Cancel on the confirmation page: DECLINED "Cancelled by user"; on the challenge: "The authentication is cancelled or abandoned"; fail it: "User Authentication Failed". Nobody pays within timeout: "Transaction timed out" (the alarm; the drawer's Let it expire now does it at once).
• A second payment with the same additional_data as one already COMPLETED: DECLINED "Duplicate transaction Duplicate transaction ID: <additional_data>".

Real vs modeled. Real (the PDF, and the live gateway as BabelPay's integration notes record it): the paths, headers, field names and validity rules, the two-step debit, the status codes and texts, the decline reasons (verbatim from production), the error codes and texts, 209's shape, the postback and its signature, the default one-hour timeout, 20 ids per status call, HTTP 400 for a status call without payment_ids (the live gateway has no listing form) and HTTP 502 for an id that is not a CC7995 payment_id. Modeled: the test cards and amount rules, the confirmation page's look (CC7995 publishes none), the HTTP statuses of errors (401 for 1/5/6, 400 otherwise; §3 says only "4xx"), the error for an unknown payment_id (1000), the ten-minute request-date window, the 25,000 cap, transaction_id and payment_method_* values, postbacks only on a final status, the duplicate rule, and the platform administration stand-in. Not simulated: 50 (no ClientId requires a beneficiary URL), 200–202, 211, recurring payments, the method web form's other methods.

Argent Platforms: cards

The Argent Platforms API on its two hosts' real paths: a client of https://api.argentplatforms.com reaches the lab at https://<lab>/argent, and of https://tokenise.argentplatforms.com at https://<lab>/argent/tokenise, and changes nothing else. Credentials are ignored: HTTP Basic with the secret key as username is taken whatever it holds; the key (hashed) only names the merchant, each key a company of its own (no credentials: lab-merchant). public_key must be present, as Argent requires it, but any value is taken. Every answer says live: false.

• POST /argent/tokenise/payment-instruments — {public_key, type: card, card_number, cvv, expiry_month, expiry_year}, JSON or form; 201 {id, type, bin, last_four}. A clear number must pass Luhn and the expiry must not be past, else 400 {"invalid-request": "The provided card details did not pass verification checks. This may be due to an invalid card number or expiry date."}. An ev: ciphertext is taken as it is and known by the X-Bistromathic-Card-Bin / -Last4 hint BabelPay sends beside it.
• POST /argent/payment-intents — immediate capture: 201 completed (with payment) or 201 failed (the processor's reason in latest_payment_attempt.error.technical_message), or 200 {requires_action: true, type, payment_intent_id, token, action_data} for 3-D Secure. GET /argent/payment-intents/{id}; GET /argent/payment-intents newest first, 20 a page, with an absolute next cursor URL on the lab's host.
• PATCH /argent/payment-intents/{id} — {public_key, token, action_data} with the one-time token: before the payer has finished, the same action again (no token); after the challenge, the payment is made and the intent comes back. A wrong or spent token: 400 {"token": ["Invalid token."]}.
• GET /argent/payments, /payments/{id} — balance, status paid / partially_refunded / refunded.
• POST /argent/refunds — {payment, amount?} (no amount: the whole balance), up to the balance; 201 RefundDetail and a refund_succeeded webhook. GET /argent/refunds, /refunds/{id}.
• GET|POST /argent/webhooks, GET|PATCH|DELETE /argent/webhooks/{id} — company must be the merchant's company id (the dashboard shows it). /balance-transactions, /disputes and /payouts list nothing.
• /argent-lab/dashboard?key={secret key} (or ?merchant=) — the stand-in for Argent's dashboard, where its docs configure webhooks: the company and its name, the signing secret, webhook URLs, the latest intents; JSON at GET|PATCH /argent-lab/dashboard/settings ({company_name, add_webhook: {url}, remove_webhook}, merchant by Basic auth). A simulated BabelPay connection subscribes its callback URL there itself.

3-D Secure. The action is a 3-D Secure 2 challenge: action_data carries acs_url, a creq and three_ds_session_data (the method card first gives three_ds_method_url and three_ds_method_data; continue with threeDSCompInd Y, N or U in action_data and the challenge follows). The payer posts the CReq to /argent-lab/acs/{token}, the issuer's challenge (two seconds to verify), whose CRes goes through the browser to Argent's 3DS server and on to the merchant's return_url with payment_intent_id and status appended. Without can_handle_3ds: true a challenge card fails ("This transaction requires authentication").

Webhooks, to every URL subscribed to the event: {id, event, created_at, live, data} (a refund's data is its RefundDetail), with X-ArgentPlatforms-Signature = hex HMAC-SHA256 of the raw body under the published simulation secret bistromathic-lab-simulated-flow (a real company's is its own signing secret).

Test cards

Lab rule

An amount ending in 5.03 (5.03, 15.03, …): the intent is created and runs as its card says, but the create answer is 503 Service Unavailable, a lost answer for reconciliation to find by reference.

Limits

• Currencies of the lab's company: USD, EUR, GBP, CAD, AUD, NZD, CHF, SEK, NOK, DKK, PLN, CZK, HUF, RON, JPY, MXN, BRL, ZAR; anything else 400 {"currency_code": ["Unsupported currency: XXX"]} (Argent's own words; its sandbox company took USD only).
• Amounts in major units, two decimal places at most, from 0.01. reference up to 255 characters, descriptor up to 18 letters, digits and spaces, return_url up to 255. browser_info, when sent, needs all eight fields.
• Not simulated, refused with a 400 naming the field: merchant_initiated: true (Argent's retry calendar and MIT test cards), flow: hosted (the hosted payment page), Apple Pay and Google Pay instruments, and a PATCH replacing payment_instrument. Records are kept a week.

Real vs modeled. Real (argent-openapi.yaml and BabelPay's sandbox run of 2026-10-27): the hosts and paths, Basic auth with the secret key, public_key in tokenise, create and continue, the tokenise → intent → PATCH → GET flow, the statuses, the 200 action answer's shape, absent values as null, string amounts, the nested currency, payment and error objects, the id prefixes, DRF's error bodies, the tokenise refusal, "Unsupported currency", payment_intent_id and status on the return, cursor pagination, the webhook events and the signature header. Modeled: the action itself (the sandbox's is a Stripe PaymentIntent for Stripe.js, which the lab cannot be), the webhook body, the refund's id prefix and refusal wording, the processors' names for the lab's cards, Stripe's decline numbers and reasons, the method card, the lost-answer rule, the currency list, the dashboard stand-in.

HappyCoins (Onramp Pay): crypto onramp

HappyCoins' Onramp Pay API on the real host's paths, under /happycoins: a client of https://dev-api-onramp-pay.up.railway.app (or https://api.onramp-pay.happycoins.com) reaches the lab at https://<lab>/happycoins and changes nothing else. The apiKey header is never checked: it only names the merchant, each key a merchant of its own (no key: lab-merchant). HappyCoins has no webhook: the merchant polls.

• POST /happycoins/api/payment/url — {customer, order:{fiatAmount, fiatCurrency}, paymentRequestId, redirectUrl, paymentMethod} (fiat in MAJOR units) answers {success:true, message:"OK", data:{paymentUrl, paymentReference, paymentRequestId}}; a refusal is 422 {"error":true,"message":"Reason: … (and N more errors)"}. paymentRequestId (a string or a number) must be unique per merchant; merchant_id, merchant_channel_id and paymentMethodGrant are accepted and kept
• GET /happycoins/api/transaction/{paymentRequestId} — keyed by the merchant's id, not by paymentReference (that is a 404 {"success":false,"message":"Not Found"}): {payment_reference, request_id, status, created_at, order_step, crypto_transactions:[{transaction_hash, crypto_currency, crypto_amount, crypto_conversion_rate, network_fee, transaction_type:"RECEIVE", status}], fiat_transaction:{fiat_amount, fiat_currency, fiat_conversion_rate, status, remarks}}
• Any other /happycoins/api/… path: 404 {"uuid":…,"message":"RESOURCE_IN_REQUEST_NOT_FOUND"}. Outside /api (bare /happycoins/transaction/{id} too): a 200 HTML page, as HappyCoins' web root answers
• /happycoins-lab/checkout?p1=…&p2=… — the hosted checkout (the paymentUrl, single-use, opaque): order and crypto, identity verification, details, order summary and card (3-D Secure through the issuer's page), the purchase, and the buyer's choice to pay the merchant or keep the crypto; then back to redirectUrl with nothing on it

Status and step move together: STARTED/INITIATED at create; IN_PROCESS through URL_VISITED, WALLET_ADDRESS, KYC_STARTED; VERIFIED/KYC_DONE; IN_PROCESS through FORM_VISITED, FORM_VISITED_DOB, FORM_SUBMITTED, ORDER_SUMMARY; PENDING/FIAT_PAYMENT while the card is charged (2 s); IN_PROCESS/PAYMENT_DONE; IN_PROCESS/SEND_TO_CUSTOMER once the crypto is in the buyer's wallet (3 s); then COMPLETED/SEND_TO_CUSTOMER when the buyer pays the merchant (where HappyCoins' paid orders stay) or COMPLETED/KEPT_BY_CUSTOMER when they keep it. DECLINED, FAILED, REJECTED, ERROR, KYC_ATTEMPT_EXCEEDED and TIMEOUT end an order where it stands; opening the link again mid-flow is RELOADED.

Magic values

• Cards (typed on the checkout, the lab's test cards; any other valid number is approved without a challenge):

  Card	Outcome
  4242 4242 4242 4242	approved, no 3-D Secure (any other valid card number too)
  5555 5555 5555 4444	approved, no 3-D Secure
  4000 0000 0000 3220	3-D Secure challenge; Confirm approves, Fail authentication is FAILED
  5200 8282 8282 8210	3-D Secure challenge, then approved
  4000 0000 0000 0341	3-D Secure challenge that fails however it is answered: FAILED (do_not_honor)
  4000 0000 0000 0002	declined, do not honor: DECLINED (do_not_honor)
  4000 0000 0000 9995	declined, insufficient funds: DECLINED
  4000 0000 0000 0119	acquirer malfunction: ERROR (psp_malfunction)

• Refused at create, as HappyCoins' sandbox refuses them: an email at a reserved domain (example.com, .test, .invalid, …), a residence in US or GB, a fiat currency outside EUR, USD, GBP, CHF, SEK, NOK, DKK, PLN, CZK, CAD, AUD (MODELED list), a paymentMethod other than CARD, a repeated paymentRequestId.
• Prices are fixed: ALGO (Algorand) EUR 0.08, USDC (Algorand) EUR 0.92, BTC (Bitcoin) EUR 61,500, ETH (Ethereum) EUR 2,450. Identity verification passes unless a rule says otherwise (3 failed attempts end the order).
• The drawer on every screen forces an outcome (COMPLETED, KEPT_BY_CUSTOMER, DECLINED, FAILED, REJECTED, ERROR, KYC_ATTEMPT_EXCEEDED, TIMEOUT) and shows the poll's answer.
• A session nobody finishes is TIMEOUT after 15 minutes; a buyer who leaves at the final choice keeps the crypto (KEPT_BY_CUSTOMER).

Lab rules (the fiat amount's last two digits in minor units)

Real vs modeled. Real (HappyCoins' guide rev. 2026-08-19, the status endpoint and vocabularies of 2026-08-24, sandbox traffic to 2026-08-31): the paths, the apiKey header, the request and response fields, major-unit amounts, the UUID paymentRequestId echoed back and its uniqueness, the 422 and 404 shapes and the messages quoted above, the restricted residences and reserved emails, the lookup by request id, the status and step vocabularies, COMPLETED/SEND_TO_CUSTOMER as a paid order's last state and KEPT_BY_CUSTOMER under COMPLETED, the crypto leg's shape and ALGO at EUR 0.0795 (1257.861635 ALGO for EUR 100.00). Modeled: the hosted checkout's screens and wording, which status accompanies each step, the other validation messages, the fiat currencies, the prices other than ALGO's, the card's test cards (HappyCoins publishes none) and the 3-D Secure step, the crypto leg's status values (In_Process, Completed, Failed), the 15-minute TIMEOUT (HappyCoins' is hours), the lab rules, and the documented delivery tail of rule …07, which HappyCoins' sandbox has never been seen to reach. crypto-accept is unspecified and not simulated.

Worldpay (WPG, Direct XML)

Worldpay's paymentService XML API (DTD v1.4) on secure-test's paths, under /worldpay: a client of https://secure-test.worldpay.com reaches the lab at https://<lab>/worldpay and changes nothing else. Credentials are ignored: any HTTP Basic merchant code and XML password are taken; the paymentService merchantCode attribute names the merchant (else the Basic username), each code a merchant of its own.

• POST /worldpay/jsp/merchant/xml/paymentService.jsp — submit/order with CARD-SSL, PAYWITHGOOGLE-SSL or EMVCO_TOKEN-SSL (Apple Pay / Google Pay network tokens), additional3DSData for 3DS Flex, third-party MPI info3DSecure, dynamic3DS, fundingTransfer (AFT, recorded); the 3DS second message (completedAuthentication, or paResponse + echoData) with the machine cookie and the same session id; modify/orderModification capture (partial), refund (partial, reference echoed in the journal), cancel, cancelOrRefund — each answered <ok><…Received>; inquiry/orderInquiry — the payment and its journal (bookingDate, accountTx amounts). Fast Access card payouts: submit/order with FF_DISBURSE-SSL (recipient/paymentInstrument/cardDetails, the recipient's address, purposeOfPayment), answered VDFF_DISBURSE-SSL (Visa Direct) or MCS_DISBURSE-SSL (Mastercard Send) with PUSH_APPROVED, PUSH_REFUSED, ERROR or PUSH_PENDING, schemeResponse (actionCode, responseCode, transactionIdentifier) and fastFunds.
• POST /worldpay/shopper/3ds/challenge.html — 3DS Flex step-up: JWT (HS256/HS512) + MD; on to the issuer's ACS, then back to the JWT's ReturnUrl with TransactionId, Response (Cardinal's JWT) and MD. A JWT signed with neither published key, or with a claim Cardinal does not permit, is an empty 400. POST /worldpay/shopper/3ds/ddc.html — device data collection (JWT, Bin): posts profile.completed with a SessionId to the parent page.
• /worldpay-lab/acs/{token} — the issuer (the shared ACS page) for 3DS Flex (creq) and legacy 3DS (PaReq, TermUrl, MD; back with PaRes).
• /worldpay-lab/mai?merchant={code} — the stand-in for the Merchant Admin Interface: where order notifications go, the name the issuer's page shows, the latest orders with their journals and the modifications WPG acknowledged and ignored. JSON at GET|PUT|PATCH /worldpay-lab/mai/settings ({notificationUrl, merchantName}; merchant = Basic username or ?merchant=). A connection in simulated flow sets both itself.

Order notifications, as WPG sends them: <notify><orderStatusEvent orderCode> with the payment and the journal entry, POSTed as text/xml, unsigned, for AUTHORISED, REFUSED, ERROR, CAPTURED, CANCELLED, SENT_FOR_REFUND, REFUNDED and REFUND_FAILED, and for a payout's PUSH_PENDING, PUSH_APPROVED and PUSH_REFUSED (the scheme named VisaDirect / MastercardSend, as Worldpay's samples spell it). Worldpay expects [OK] in the answer; the lab logs an answer without it.

3DS Flex keys: challenge and DDC JWTs verify with the simulation secret bistromathic-lab-simulated-flow (what a connection in simulated flow signs with) or Worldpay's published secure-test credentials (iss 5bd9e0e4444dce153428c940, OrgUnitId 5bd9b55e4444761ac0af1c80, MAC key fa2daee2-1fbb-45ff-4444-52805d5cd9e0). The Response JWT is signed with the same key.

Magic values (Worldpay's)

• Cardholder name: AUTHORISED, REFUSED (ISO 5), REFUSED<n> (ISO n; REFUSEDR1/R3 = 973/975), ERROR. ISO wording: 4 HOLD CARD · 5 REFUSED · 8 APPROVE AFTER IDENTIFICATION · 13 INVALID AMOUNT · 15 INVALID CARD ISSUER · 17 ANNULATION BY CLIENT · 28 ACCESS DENIED · 29 IMPOSSIBLE REFERENCE NUMBER · 33 CARD EXPIRED · 34 FRAUD SUSPICION · 38 SECURITY CODE EXPIRED · 41 LOST CARD · 43 STOLEN CARD, PICK UP · 51 LIMIT EXCEEDED · 55 INVALID SECURITY CODE · 56 UNKNOWN CARD · 57 ILLEGAL TRANSACTION · 62 RESTRICTED CARD · 63 SECURITY RULES VIOLATED · 75 SECURITY CODE INVALID · 76 CARD BLOCKED · 85 REJECTED BY CARD ISSUER · 973 Revocation of authorization order · 975 Revocation of all authorizations order. Any other name authorises.
• 3D — legacy 3DS: request3DSecure (paRequest, issuerURL, echoData), the issuer's page, PaRes; 3D.REFUSED13 then refuses. NO3D (and NO3D.<value>) — "Authentication Offered but not Used" (Amex: "Ecommerce").
• 3DS Flex names (with additional3DSData; without it they authorise without 3DS):

  3DS_V2_FRICTIONLESS_IDENTIFIED	Frictionless, cardholder authenticated
  3DS_V2_FRICTIONLESS_NOT_IDENTIFIED	Frictionless attempted: offered but not used
  3DS_V2_FRICTIONLESS_REJECTED	Frictionless rejected: REFUSED, not sent for authorisation
  3DS_V2_FRICTIONLESS_VALID_ERROR	Frictionless, authentication unavailable
  3DS_V2_CHALLENGE_IDENTIFIED	Challenge, cardholder authenticated
  3DS_V2_CHALLENGE_VALID_ERROR	Challenge, then authentication unavailable
  3DS_V2_CHALLENGE_UNKNOWN_IDENTITY	Challenge, authentication attempted but failed: REFUSED
  3DS_BYPASSED	3DS bypassed
  3DS_V2_BYPASSED_AFTER_CHALLENGE	Challenge, then bypassed
  3DS_V1_CHALLENGE_IDENTIFIED	3DS1 challenge, cardholder authenticated
  3DS_V1_CHALLENGE_UNKNOWN_IDENTITY	3DS1 challenge, authentication failed: REFUSED

• Cardinal's 3DS 2 test cards (with additional3DSData), the name then steering the authorisation:

  #	Case	Visa	Mastercard	Amex
  1	Successful frictionless	4000000000001000	5200000000001005	340000000001007
  2	Failed frictionless: REFUSED	4000000000001018	5200000000001013	340000000001015
  3	Attempts stand-in	4000000000001026	5200000000001021	340000000001023
  4	Issuer unavailable	4000000000001034	5200000000001039	340000000001031
  5	Issuer rejected: REFUSED	4000000000001042	5200000000001047	340000000001049
  6	Not available on lookup	4000000000001059	5200000000001054	340000000001056
  7	Error on lookup	4000000000001067	5200000000001062	340000000001064
  8	Lookup timeout	4000000000001075	5200000000001070	340000000001072
  9	Bypassed authentication	4000000000001083	5200000000001088	340000000001080
  10	Successful step-up (challenge)	4000000000001091	5200000000001096	340000000001098
  11	Failed step-up (challenge): REFUSED	4000000000001109	5200000000001104	340000000001106
  12	Step-up unavailable (challenge)	4000000000001117	5200000000001112	340000000001114
  13	Error on authentication (challenge)	4000000000001125	5200000000001120	340000000001122

• Test cards: 4444333322221111 Visa (VISA-SSL), 4917610000000000 Visa Debit (VISA_DEBIT-SSL), 4462030000000000 Visa Debit (VISA_DEBIT-SSL), 5555555555554444 Mastercard (ECMC-SSL), 5454545454545454 Mastercard (ECMC-SSL), 2221000000000009 Mastercard (2-series) (ECMC-SSL), 5163613613613613 Mastercard Debit (ECMC_DEBIT-SSL), 6759649826438453 Maestro (MAESTRO-SSL), 343434343434343 American Express (AMEX-SSL), 4562686000117661 Cartes Bancaires (CB-SSL), 36700102000000 Diners (DINERS-SSL), 36148900647913 Diners (DINERS-SSL), 6011000400000000 Discover (DISCOVER-SSL), 3528000700000000 JCB (JCB-SSL), 6221260000000000 UnionPay (CHINAUNIONPAY-SSL), 122000000000003 Airplus (AIRPLUS-SSL). Any other clear card number must pass Luhn (error 7 otherwise); an expired card is error 7 Expiry date = MM/YYYY.
• Mastercard / Maestro magic amounts: 1000 AUTHORISED, 310 REFUSED, 320 ERROR (minor units, when the name is no magic value).
• CVC (CVCResultCode): 111/222/333 not sent / no response / not checked, 444 FAILED, 555 APPROVED (Amex 1111…6666), blank NOT SUPPLIED BY SHOPPER. AVS from the postal code: AAAAA APPROVED … JJJJJ FAILED … MMMMM UNKNOWN.
• Google Pay: the magic value in the order description (BabelPay sends Payment <merchant reference>; the lab reads its last word). Network tokens: the token's cardHolderName or the description.

Fast Access payouts (Worldpay's disbursement test values)

• The recipient's cardHolderName:

  APPROVED	PUSH_APPROVED, action code 00
  REFUSED	PUSH_REFUSED, action code 01
  REFUSED14	PUSH_REFUSED, action code 14 (invalid account number)
  REFUSED54	PUSH_REFUSED, action code 54 (expired card)
  REFUSED57	PUSH_REFUSED, action code 57 (not permitted to cardholder)
  REFUSED61	PUSH_REFUSED, action code 61 (exceeds amount limit)
  REFUSED62	PUSH_REFUSED, action code 62 (restricted card)
  PENDINGAPPROVED	PUSH_PENDING, then PUSH_APPROVED 15 s later, with an order notification
  PENDINGREFUSED	PUSH_PENDING, then PUSH_REFUSED (action code 05) 15 s later, with an order notification
  ERROR	ERROR

  REFUSED<nn> refuses with any other two-digit action code too (the lab's generalisation). Any other name is approved (Worldpay's token-based test flow answers ERROR; the lab approves, so a payout to a real-looking name just works).
• Visa cards go through Visa Direct, Mastercard and Maestro through Mastercard Send; any other brand is error 7. Cards: 4917300800000000 Visa credit, GB, GBP: no fast funds, 4462030000000000 Visa credit, NL, EUR: no fast funds, 4484070000000000 Visa credit, AU, AUD: no fast funds, 4485602020200027 Visa credit, HK, HKD: no fast funds, 4499232020200027 Visa credit, SG, SGD: no fast funds, 4000765339615288 Visa credit, US, USD: no fast funds, 4000765339615296 Visa credit, US, USD: no fast funds, 5551593000060026 Mastercard credit, GB, GBP: no fast funds, 5555555555554451 Mastercard credit, GB, GBP: no fast funds, 5555555555554477 Mastercard credit, NL, EUR: no fast funds, 5555555555554493 Mastercard credit, AU, AUD: no fast funds, 5454545454545751 Mastercard credit, issuer country unknown: no fast funds, 4895070000006687 "Invalid billing card currency code received from Visa.", 4895070000007685 "Invalid issuer country code received from Visa."; any other card has fast funds.
• Mastercard Send's data validation: a blank name (the lab asks it of Visa too), a name of digits only (error 5, Worldpay's wording).

Lab rules

• With 3DS Flex on and no 3DS magic value or test card, authentication is frictionless and authenticated; dynamic3DS do3DS or challengePreference challengeRequested/Mandated asks for a challenge; no3DS skips 3DS.
• Wallet orders (opaque tokens), with no magic value:

  …51, from 10.00	REFUSED, ISO 51 LIMIT EXCEEDED
  …99, from 10.00	Google Pay with 3DS data (a card saved in the Google account): a 3DS Flex challenge
  …05, from 10.00	REFUSED, ISO 5 REFUSED

• captureDelay 0 / DEFAULT: CAPTURED 10 s after AUTHORISED (WPG: minutes to an hour); 1–14: after that many days; OFF: never. A refund is SENT_FOR_REFUND, then REFUNDED 10 s later.
• A payout is never captured, cancelled or refunded: a modification of one is acknowledged <ok> and ignored.

Real vs modeled. Real (docs.worldpay.com): the path, the XML elements and reply shapes the client reads (orderStatus/payment/lastEvent, ISO8583ReturnCode, ThreeDSecureResult with eci/cavv, challengeRequired/threeDSChallengeDetails, request3DSecure + echoData, the machine cookie, <ok> receipts, journals), the error codes (2 parse, 3 amount, 5 duplicate order / not found / currency, 7 payment details), the magic names, cards, amounts, CVC and AVS values, Cardinal's cases, the step-up's claims and empty 400, the published test JWT credentials; for payouts, the FF_DISBURSE-SSL request (the DTD's), the PUSH_* statuses, schemeResponse and fastFunds, the disbursement magic names and cards, Mastercard Send's validation messages. Modeled: the wording of the lab's own error 5 messages (machine cookie, session id, 3DS not completed), out-of-band modification failures (booked as nothing, a refund over the captured amount as REFUND_FAILED), the capture, refund and pending-push timings, the lab's frictionless default and wallet rules, the issuer's page, the MAI stand-in, an ordinary payout name approved, the action code 05 of a PENDINGREFUSED, the error-simulation cards answered as error 5. Not simulated: "Order not ready" inquiry lag, HPP, tokenisation (payouts to a token), card checks, Money Transfer OCTs (FF_MONEYTRANSFER-SSL), batch orders, settlement (SETTLED, SETTLED_BY_MERCHANT), chargebacks.

Citigate (Orion card gateway)

Citigate's JSON interface (Integration Specification, Credit Card v1.27) on the real host's path, under /citigate: a client of https://gw-test.cgate.tech/orion/interface/json.ashx (or gw.cgate.tech) reaches the lab at https://<lab>/citigate/orion/interface/json.ashx and changes nothing else. One POST, the operation picked by TransTypeID; every answer is HTTP 200 with Citigate's fields (TransactionID as text, TransTypeID, Amount and ResponseCode as numbers). Credentials are ignored: MerchantName only names the merchant (each its own MID; none: lab-merchant), MerchantPassword is never read.

• TransTypeID 0 Purchase — approved (0), declined (bank codes below 500), refused by the gateway (field codes 500–556, 568, 597; TransTypeID 0, TransactionID "0"), or 600 Redirect required with a RedirectURL
• 3 Capture and 4 Cancel — an open authorisation, in full (560–562, 589 when MerchantRef is not the original's)
• 5 Refund — a sale or a captured authorisation, by the purchase's or the capture's TransactionID; Amount optional (the rest); 563, 564, 629, 630
• 7 Recurring — re-bills an approved purchase without the card; 621 on a 3D MID, 622 without an approved initial purchase
• 8 Status — the latest purchase with that MerchantRef: TransTypeID 6 + 999 Transaction Pending during a redirect, 99 + 999 MerchantRef not found, or the purchase's own answer
• /citigate/redirect/processing.aspx?{token} — the RedirectURL: Citigate's "Transaction in progress", then the issuer's challenge (/citigate-lab/acs, the lab's shared 3-D Secure page) when the card asks for one, then "Your transaction is being finalized" (/citigate/redirect/complete.aspx), which POSTs the callback, waits for its answer, and returns the payer to SuccessURL (approved) or FailURL with the same fields as a form. &device=mobile|desktop forces either layout

Callback and user return, as Citigate sends them on the JSON interface: a JSON POST to CallbackURL with every response field as text plus Signature = lowercase hex SHA-1 of MerchantPassword + TransactionID + MerchantRef + Currency + Amount + ResponseCode. The lab signs with the published simulation secret bistromathic-lab-simulated-flow in the MerchantPassword's place; a connection in simulated flow verifies with it.

Magic values

• Appendix 2's test merchants: Dummy1 (non-3D MID, authorisations, the amount decides: USD/EUR up to 999.99 approves, 1000.00 or more declines with 5) and Dummy2 (3D MID, sales, every purchase redirects; the challenge decides: confirm → 0, fail → 103, cancel → 106). Password p@s5w0Rd123, not checked.
• Any other MerchantName (a simulated connection's is simulated-<connection id>) is the lab's MID: authorisations, the same USD/EUR amount rule, then the cards below; any other Luhn-valid card approves with no redirect. Partial refunds are on.

An encrypted card (ev:…) is recognised by BabelPay's BIN and last-four headers. Expiry any future month, CVV any 3 or 4 digits.

Checked, with Citigate's codes

• MerchantRef (501/502), Currency (503/504; 568 unknown), Amount (505/506), CardNo (539/540, Luhn 553), Brand (511/512; not required of an encrypted card), expiry (541–544, 554 expired), CVV (545/546), UserIP (535/536), Country/Email/DateOfBirth formats (528/530/534), and for Country=US StateProvince, Telephone and DateOfBirth (525/531/533).
• SuccessURL, FailURL, CallbackURL (584–586) whenever the purchase redirects.
• 597: a successful purchase with the same card, MID, currency and amount in the last 30 seconds.
• The clock: 15 minutes to open the RedirectURL (700), 15 more to come back (800), each with the signed callback; open authorisations auto-captured after 48 hours.

Real vs modeled. Real (Citigate.pdf v1.27): the endpoint, the TransTypeIDs, the field names, Appendix 1's codes and texts, the 600 → redirect → callback → user-return sequence with the callback joined before the return, the SHA-1 signature, the pending/unknown status answers, Dummy1/Dummy2 and the amount rule, the 30-second duplicate guard, partial refunds off by default, auto-capture. Modeled: the decline code of the amount rule (5), TransTypeID 0 / TransactionID "0" on a refused request, the timeout lengths, 589 for a MerchantRef that is not the original's, a refund answering the refunded amount, the lab's MID and test cards, Brand not required of an encrypted card, the payer's name and address fields not required (Citigate marks them mandatory; the sandbox's enforcement is not documented). Not served: the SOAP, XML and NVP interfaces, the Refund and Fraud Notifications (an optional push, off by default), and RaaS (TransTypeID 31 answers 573).

Blueemi (Checkout.com's Unified Payments API)

Blueemi is a white-label of Checkout.com's Unified Payments API, and the lab serves that API on the real host's paths, under /blueemi: BabelPay's blueemi connector in simulated flow swaps the Evervault relay in front of api(.sandbox).checkout.com for https://<lab>/blueemi and changes nothing else. Credentials are ignored: any Authorization: Bearer key is taken and only names the merchant (a simulated connection sends simulated-<connection id>; any other key names its merchant by a hash and is never kept). The card arrives as vault ciphertext with its BIN and last four in X-Bistromathic-Card-Bin / -Last4, or in clear.

• POST /blueemi/payments — a card source: 201 Authorized or Declined (response_code, response_summary), or with 3ds.enabled and a card with a 3DS profile 202 Pending with _links.redirect. capture (default true) captures behind the authorization. Amount 0 is a card verification. Authentication done elsewhere (3ds.eci + cryptogram) is authorized as sent. 422 {request_id, error_type: "request_invalid", error_codes}.
• GET /blueemi/payments/{pay_…|sid_…} — the payment; actions (latest first) only when looked up by the cko-session-id, which expires after 15 minutes. GET /blueemi/payments?reference=, GET /blueemi/payments/{id}/actions. Unknown: 404, no body.
• POST /blueemi/payments/{id}/captures (partial; capture_type Final closes the rest) · /voids (before the capture) · /refunds (up to what was captured) — 202 {action_id, reference, _links}; 403 with no body when the action is not allowed; 422 capture_value_greater_than_authorized, void_amount_invalid, amount_exceeds_balance.
• /blueemi-lab/3ds/{token} — the hosted 3DS page: two seconds of device data, then frictionless or the issuer's challenge (Confirm / Cancel; "Fail authentication" in the drawer), then back to success_url or failure_url with ?cko-session-id=sid_… (303). The drawer also lets the session expire. ?device=mobile|desktop forces either.

Webhooks, Checkout.com's envelope {id: "evt_…", type, version, created_on, data: {id, action_id, reference, amount, currency, response_code, response_summary, balances, source, …}, _links}, signed blueemi-Signature = hex HMAC-SHA256(key, raw body), the key being the published simulation key bistromathic-lab-simulated-flow. The lab has no dashboard: they go to the callback_url in the payment's metadata. Events: payment_approved, payment_declined, payment_captured / _capture_declined, payment_voided / _void_declined, payment_refunded, card_verified / card_verification_declined; a refund's or capture's event carries that action's id, amount and reference.

Test cards (Checkout.com's): the issuer's answer

Any future expiry (a past one: 422 card_expired); a 3-digit CVV, 4 for American Express. A card with no 3DS profile is not enrolled: with attempt_n3d it is authorized at once without 3DS (3ds.downgraded: true), without it declined 20150.

3DS test cards

Authenticated (Y) or attempted (A): authorized, then the amount rules decide. Not authenticated (N) or rejected (R): declined 20151. Could not be performed (U) or a scheme error (E): with attempt_n3d authorized without liability shift (ECI 07/00), otherwise 20153. A challenge cancelled or failed is not authenticated.

Amount rules (any other card, and 3DS cards after authentication)

From Checkout.com's earlier sandbox documentation, in minor units; an expiry of 01/2099 skips them. Any other amount approves.

2011 → 200R1 Issuer initiated a stop payment (revocation order) for this authorization
2013 → 200R3 Issuer initiated a stop payment (revocation order) for all authorizations
4001 → 40101 Risk Blocked Transaction
4008 → 40108 Gateway Reject - Post code failed
9998 → 20068 Response received too late / Timeout
…12 → 20012 Invalid transaction
…14 → 20014 Invalid account number (no such number)
…33 → 30033 Expired card - Pick up
…51 → 20051 Insufficient funds
…54 → 20087 Bad track data (invalid CVV and/or expiry date)
…62 → 20062 Restricted card
…63 → 20063 Security violation
…05 → 20005 Declined - Do not honour (from 1.00)
With 3DS on, any other card: 6900 or ending in 150 → 20150, 5000–5029 → 20153, 6510/6520/6530/6540 → 20154, at once.

Real vs modeled. Real (checkout.com/docs, api-reference.checkout.com): the paths, the 201/202/403/404/422 answers and bodies, statuses and their casing, pay_/act_/sid_/src_/cus_/evt_ ids, the balances, actions only by session id, the 15-minute session, the webhook envelope and its hex signature, the test cards and response codes. Modeled: the hosted 3DS page's look (Checkout's sandbox shows its own simulator, password Checkout1!), which cards have a 3DS profile (only the 3DS tables'), what U/E results and a cancelled challenge lead to, the earlier sandbox's amount rules applied to every other card, webhooks to metadata.callback_url (two attempts, not Checkout's eight over 24 hours), captures/voids/refunds settling at once. Payouts, tokens, instruments, customers' API, incremental authorizations and idempotency keys are not simulated.

Pay.nl

Pay.nl's Order API (the TGU, connect.pay.nl/v1) and its Transaction:Refund (rest.pay.nl/v2) on the real hosts' paths, under /paynl: a client of https://connect.pay.nl (or its failover core connect.payments.nl) and https://rest.pay.nl reaches the lab at https://<lab>/paynl for both and changes nothing else. Credentials are ignored: any HTTP Basic pair is taken; the username (the AT code) only names the merchant, each its own (no credentials: lab-merchant). The sales location's boarded methods: 10 iDEAL (EUR only), 436 Bancontact (EUR only), 11 Creditcard, 138 PayPal, 1717 Klarna, 2970 Pay by Bank (EUR only), 2277 Apple Pay, 2558 Google Pay, 613 Sandbox.

• POST /paynl/v1/orders — Order:Create: status 20, links.redirect to the hosted checkout; serviceId (SL-####-####) and amount.value (minor units) are checked, with paymentMethod.id, currency per method, Klarna's address
• GET /paynl/v1/orders/{id}/status — Order:Status, with payments[] naming the payer (customerType/customerId/customerName, an IBAN for iDEAL and Pay by Bank, the email for PayPal)
• PATCH /paynl/v1/orders/{id}/capture, …/capture/amount, …/void (−61), …/abort (−90), …/approve, …/decline (−64) — the order's answer, Order.Output
• PATCH /paynl/v2/transactions/{orderId | EX code}/refund — Transaction:Refund with {amount: {value, currency}}; partial refunds up to what was captured; the legacy order id (52305407020X2325), never the order UUID
• /paynl-checkout/to/order/{token} — the payer: Pay.nl's checkout and the method's own screens (card form with the issuer's 3-D Secure, iDEAL's bank list and the bank, Pay by Bank in NL, BE, DE, AT, PayPal, Klarna, Bancontact with its app, Apple Pay, Google Pay, the sandbox of method 613). ?device=mobile|desktop forces either

Exchanges, as SIGNED_JSON_POST: {event: "status_changed", type: "order", version: 1, id, object: <the order>} to the order's exchangeUrl (with type, id, event added to its query, for logging), headers signature = hex HMAC-SHA256 of the raw body, signature-method: HMAC, signature-algorithm: SHA256, signature-keyid: <SL code>. The key is the published simulation secret bistromathic-lab-simulated-flow (a real merchant's is its sales location's secret). Sent when an order is paid, authorised, held for VERIFY, voided, denied, failed, cancelled or expired (not for PENDING); Pay.nl wants {"result": true} back. A refund call with its own exchangeUrl gets refund:add and refund:received.

Magic values

Pay.nl's own test mode is its sandbox: "What should be the next payment status?" — Captured / Paid (100), Authorised (95), Aborted (-90), Pending (50), Cancelled (-90), Verify (85), Failed (-60), Denied (-64), Declined (-64), Expired (-80). The lab has it in the drawer of every screen (and as the page of payment method 613), and Pay.nl publishes no other test values. Cards (Pay.nl publishes none; the lab's own, typed on the hosted page):

Lab rules

Limits and checks, with Pay.nl's errors ({type, code, title, detail, violations}; the refund API's {type, title, detail, violations[{propertyPath, message, code}]}): an order of 0.01 to 50,000 (PAY-2002 / PAY-2003); iDEAL, Bancontact and Pay by Bank in EUR only (PAY-2123); Klarna needs the email and invoice address (PAY-2119); capture and void only on an authorisation (95/97), abort only while open, approve/decline only in VERIFY; a refund only once paid, up to what was captured (PAY-2125), and the same refund twice within 15 seconds is "Refund too fast" (PAY-3000). Orders expire after 15 minutes unless expire says otherwise; authorisations after 7 days.

Real vs modeled. Real (developer.pay.nl): the paths and methods, Order.Output and its ids' shapes, the status codes, the sandbox's statuses, the exchange body and signature, the refund response, the error bodies and codes, Klarna as an authorisation. Modeled: the lower-case status names beyond new/pending/captured, the method screens (Pay.nl's test mode shows only its sandbox), which errors answer 400 or 422, the 15-minute expiry, one payment attempt per order (a declined card ends the order), Pay by Bank's 5 seconds at 98, the refund rate limit's window, the cards, the lab rules. Refunds leave the order's status at 100 (Pay.nl's −81/−82 are transaction statuses).

Orchid (Gate API)

Orchid's Gate API on the real host's paths, under /orchid: a client of https://api.orchid.works reaches the lab at https://<lab>/orchid and changes nothing else. Every request is JSON with a general object; general.project_id names the project (each a merchant of its own). Credentials are ignored: any project id is a project, and general.signature must be present (3262 when empty) but is never checked.

• POST /orchid/v2/payment/card/sale, /card/auth — acknowledged ({status: "success", request_id, project_id, payment_id}); the outcome follows in callbacks
• POST /orchid/v2/payment/card/3ds_check_iframe, /card/3ds_result — the 3-D Secure continuations
• POST /orchid/v2/payment/card/capture, /card/cancel (a hold only), /card/refund; /v2/payment/applepay/sale and /applepay/refund
• POST /orchid/v2/payment/card/payout — a payout to a card, never 3-D Secure
• POST /orchid/v2/payment/status — authoritative, signed; an unknown payment is {payment:{status:"error"}, errors:[{code:"3061"}]}
• /orchid-lab/acs/{project}/… — the card issuer's ACS: the 3DS Method (in the merchant's hidden iframe; it notifies acs_return_url.3ds_notification_url), the challenge (CReq), the basic workflow's PaReq; the result goes back to acs_return_url.return_url as cres + threeDSSessionData (basic: PaRes + MD to the TermUrl)

Callbacks go to general.merchant_callback_url, signed the Gate way (every parameter flattened, natural sort, HMAC-SHA512, Base64, top-level signature) with the published simulation secret bistromathic-lab-simulated-flow, which a connection in simulated flow uses as its project secret key. The same signs status answers.

The clock

• No 3-D Secure: processing (9999), the outcome after 1.5 s.
• 3-D Secure 2, extended workflow (the sale has acs_return_url): after 3 s awaiting 3ds result and the callback with threeds2.iframe; 1.5 s after 3ds_check_iframe (or 30 s without it, as the method had not completed) the frictionless outcome, or the callback with threeds2.redirect (creq, threeDSSessionData); the outcome 1 s after 3ds_result. No 3ds_result within 30 min: declined 108.
• Basic workflow (no acs_return_url.return_url): the callback with acs {acs_url, pa_req, md}, then 3ds_result with pares.
• A 3ds_check_iframe on a payment already concluded drops it back to processing with 3060 and the acquirer's 11206, for good — as Orchid did to prod tx ae9c5ded.
• Capture, cancel and refund apply at once; their callback follows. A refund is refused in its callback (3281 status, 3283 / 903 amount, 3284 currency, 3285 within two minutes of the last), never in the answer.

Orchid's test cards

Decided by the card number alone (any holder, CVV, future expiry). Encrypted cards are recognised by the BIN and last four BabelPay sends beside them.

Lab rules (other cards: last two digits of the amount in minor units)

A refund amount ending in …28 is declined 3028 (merchant balance). At the issuer's page, Confirm authenticates, "Fail authentication" declines 104, Cancel declines 301.

Real vs modeled. Real (developers.orchid.works, gate-spec.json): the paths, the general object, the ack, the error envelope and info codes, the payment and operation statuses, the callback and status bodies, the signature, the 3-D Secure callbacks (threeds2.iframe with 3DSMethodData/threeDSMethodData, threeds2.redirect with creq/threeDSSessionData, acs), the 30-minute ACS window and 108, the test cards, the refund rules, a payout on /card/payout. From BabelPay's own production record: the Apple Pay decrypted-token form, the 702 callback with errors for a request Gate cannot process (e.g. merchant-side authentication data without xid, which Gate's schema requires), the de-finalizing 3ds_check_iframe. Modeled: the timings, which code a test card declines with where Orchid names none (10000, 10114, 10602), 104 / 301 at the ACS, refunds after the business day (refunded, never same-day reversed), the lab rules, the ACS pages. Not simulated: the edge's HTML 400/429 under bursts, credential-on-file, tokens, Google Pay's encrypted etoken, AVS and clarification.

Nuvei

Nuvei's (ex-SafeCharge) REST API 1.0, on the real hosts' own paths under /nuvei: a client of https://ppp-test.nuvei.com/ppp/api/v1 (integration) or https://secure.safecharge.com/ppp/api/v1 (production) is pointed at <lab>/nuvei/ppp/api/v1 instead. Cards server to server with 3-D Secure 2, iDEAL (apmgw_iDeal) as a redirect APM, refunds, voids, settles and card payouts. Every merchantId is a merchant of its own.

Credentials are ignored: every request must carry merchantId, merchantSiteId, a 14-digit timeStamp and a checksum (SHA-256 of the documented fields and the merchant secret key), but no request is refused for the checksum's value. The DMN's advanceResponseChecksum — SHA-256 of the secret key, totalAmount, currency, responseTimeStamp, PPP_TransactionID, Status and productId — is signed with the published simulation secret bistromathic-lab-simulated-flow, which a connection's "Simulated flow" takes as its merchant secret key.

• POST /nuvei/ppp/api/v1/getSessionToken.do, openOrder.do — a session token (sessions live 30 minutes, modeled)
• POST /nuvei/ppp/api/v1/initPayment.do — InitAuth3D: threeD.v2supported says whether the card is enrolled
• POST /nuvei/ppp/api/v1/payment.do — a card payment: non-3DS, 3DS (threeD and relatedTransactionId = the InitAuth3D: frictionless Sale, or an Auth3D REDIRECT with threeD.acsUrl and cReq), the liability shift after a challenge (relatedTransactionId = the Auth3D, no threeD), or an APM (paymentOption.alternativePaymentMethod: REDIRECT to paymentOption.redirectUrl). transactionType Auth authorises only
• POST /nuvei/ppp/api/v1/refundTransaction.do, voidTransaction.do, settleTransaction.do — on relatedTransactionId; refunds partial or full up to the payment
• POST /nuvei/ppp/api/v1/payout.do — an OCT to userPaymentOption.userPaymentOptionId (a UPO an approved payment made for the userTokenId) or to cardData (the cardholder name required, filter 1210); up to 10000.00 (filter 1126 above, modeled)
• POST /nuvei/ppp/api/v1/getPaymentStatus.do (the session's last payment), getTransactionDetails.do (by transactionId or the latest with a clientUniqueId), getPayoutStatus.do (by the payout's clientRequestId)
• POST /nuvei/ThreeDSACSEmulatorChallenge/api/ThreeDSACSChallengeController/ChallengePage?<token> — the issuer's challenge (the shared ACS page); the CRes is posted to threeD.notificationURL as cres. Unanswered for 10 minutes, the authentication expires (filter 1278)
• /nuvei/apm/Home?PaymentToken=… — the iDEAL page: the bank list (on a computer, the QR code and the payer's phone beside it); Nuvei's sandbox bank TESTNL2A offers the outcome to pick. 15 minutes to pay (modeled), then a DECLINED DMN. ?device=mobile|desktop forces either flow

DMNs are POSTed form-encoded to urlDetails.notificationUrl (Nuvei takes HTTP 200, retried once after five seconds here): every final card payment, refund, void, settle and payout; an APM payment's PENDING at once and its end later. Duplicate clientRequestIds are refused (1089).

Test cards (Nuvei's own)

Any CVV and future expiry. For a 3DS card the cardholder name picks the flow: FL-BRW1 (FL-…) frictionless, CL-BRW1 (CL-…) a challenge, ERR-BRW1 (ERR-…) the Directory Server's error (filter 1277); any other name is frictionless. Any card number not listed is a 3DS card that approves.

Lab rules

Gateway filter errors (gwErrorCode -1100)

Real or modeled

• Real (docs.nuvei.com, REST API 1.0): the paths, the request and response fields, the checksum fields, advanceResponseChecksum, the 3DS server-to-server flow (initPayment, payment, CReq/CRes, the liability shift), the test cards and cardholder names, the 83.10 / 115.20 amount cards, errCodes and gateway filter codes, the iDEAL BIC list and its sandbox bank TESTNL2A.
• Modeled: the session lifetime, the challenge's and the iDEAL page's expiry, the payout ceiling, the ACS and iDEAL pages (the lab's own drawings), responsechecksum (deprecated), the lab rules, no 3DS fingerprinting (methodUrl is empty).

MiFinity

MiFinity's eWallet API on its own paths, under /mifinity: a MiFinity client swaps https://demo.mifinity.com for this host's /mifinity. The API is real, built from MiFinity's public docs (mifinity.readme.io and its llms.txt). Credentials are ignored: any key header is taken and names the merchant (its sessions, payouts, MiFinity users and balances); x-api-version and X-MiFinity-Signature are not checked. The cashier is redrawn from the screenshots in MiFinity's docs; the MiFinity app on the phone beside it is the lab's (the docs show none). Errors whose codes MiFinity does not publish (validation, limits, an unknown payee, insufficient funds) are the lab's.

• POST /mifinity/api/gateway/init-iframe/: the session, initializationToken and, with entry: "hosted", iframeEntrypoint (/mifinity/iframe2#initToken=…). The token lasts 30 minutes. /mifinity/widgets/sgpg.js serves showPaymentIframe for the embedded widget.
• GET /mifinity/api/gateway/payment-status/{validationKey}: NOT_COMPLETED, PENDING, SUCCESSFUL (with paymentResponse) or FAILED (with detailedStatus).
• Callbacks: a paid deposit is POSTed to returnUrl (the payment response, customerDob as [y, m, d]), a failed one to errorUrl (ABANDONED_BY_USER, REFUSED_BY_RISK, FAILED). MiFinity signs neither: the validationKey the merchant made comes back in them. responseCode is an HMAC-SHA256 under the published secret bistromathic-lab-mifinity-response-code-2026-11-12 over traceId|validationKey|transactionReference (the lab's; MiFinity's is undocumented).
• POST /mifinity/api/payments/acct2acct/: synchronous, to an email or account number; 200 with status: "OK" means paid. POST /mifinity/api/payments/pab: PayAnyBank to a SEPA IBAN (IBAN, BIC, BANK_NAME, CUSTOMER_NAME, _ADDRESS, _CITY, _ZIP): Received, Submitted after 1 s, Processed by acquirer after 6 s (MiFinity: the next day). Notification callbacks (statuses 3, 5, 6) go to the URL set with PUT /mifinity-lab/portal?apiKey=… {"callbackUrl", "merchantName"} (lab only: MiFinity's integration team sets it up by email) and want 200 with no body.
• GET /mifinity/api/transactions/status/{traceId}, /api/transactions/{reference}/status (1, 2, 3, 5, 6, 7, 8; 404 ELEMENT_NOT_FOUND), GET /mifinity/api/currencies.

Deposit limits (MiFinity's): EUR 10–2,500, GBP 10–2,500, USD 10–2,500, AUD 10–4,000, CAD 10–3,750, CZK 250–65,000, NZD 10–4,000, PLN 50–10,500, SEK 100–25,000, CHF 10–2,500, DKK 75–18,500, ZAR 175–42,500, JPY 1500–325,000, NOK 100–23,750, RUB 850–200,000, CNY 10–2,500, INR 875–200,000; other currencies convert to EUR. PayAnyBank's limits are MiFinity's too (EUR 10–10,000). The merchant's account opens with 100,000.00 in each eWallet currency; payouts carry the lab's 1 % fee. The demo's card verification code is 1234.

MiFinity users (the lab's; any password, wrong fails)

Lab rules (amount, from 10.00, last two digits)

TrueLayer

TrueLayer's Payments API v3 on its own paths, under /truelayer: a TrueLayer client swaps each TrueLayer host (auth.truelayer-sandbox.com, api.truelayer-sandbox.com, payment.truelayer-sandbox.com, webhooks.truelayer-sandbox.com) for this host's /truelayer. Credentials are ignored: any client_id and client_secret get a token at POST /truelayer/connect/token, and the token names the client (its payments, its GBP and EUR merchant accounts with 1 000 000.00 each, its webhook URI). Tl-Signature on requests is not checked; Idempotency-Key is required and honoured (the same key with another body is 422 Idempotency-Key Reuse). The API is real: built from TrueLayer's public OpenAPI (payments-api-v3.json), signing spec and docs. The real banks' provider ids and limits, the lab's amount rules and the timings are the lab's.

• POST /truelayer/v3/payments (bank_transfer, user_selected or preselected provider, merchant_account or external_account beneficiary, hosted_page), GET /v3/payments/{id}, POST /v3/payments/{id}/actions/cancel, POST|GET /v3/payments/{id}/refunds, GET /v3/payments/{id}/refunds/{refund_id}, POST /v3/payouts (payment_source, external_account by IBAN or sort code and account number), GET /v3/payouts/{id}, GET /v3/merchant-accounts, /{id}, /{id}/payment-sources?user_id=
• /truelayer/checkout/payments#payment_id=…&resource_token=…&return_uri=… — the hosted payment page: the bank picker with search, consent, on a computer a real QR code to continue in the banking app (the phone is drawn beside the page; a real phone's camera works too), the bank's app or website, TrueLayer's mock bank, the result, and back to return_uri?payment_id=… (&error=tl_hpp_abandoned when the payer cancelled). ?device=mobile|desktop forces either flow.
• PUT /truelayer-lab/console/settings {"webhook_uri": "…", "merchant_name": "…"} (lab only) — what TrueLayer Console holds: the client's webhook URI. Without one, no webhooks are sent.

Webhooks go to the webhook URI with X-Tl-Webhook-Timestamp and Tl-Signature (ES512, tl_headers: X-Tl-Webhook-Timestamp, over POST and the URI's path) by the lab's published key, whose JWKS is at /truelayer/.well-known/jwks (the jku): payment_executed, payment_settled (with payment_source.id and user_id, for closed-loop payouts), payment_failed, refund_executed, refund_failed, payout_executed, payout_failed. A payment executes 1.5 s after the bank approves and settles 2 s later; a payout or refund executes 2 s after it is authorised (a refund once its payment has settled). The resource token lasts 15 minutes.

TrueLayer's mock bank (mock-payments-*-redirect)

Lab rules (at a real bank)

A payout to an IBAN ending 9901 fails invalid_iban; to an account number ending 9902, invalid_scan. Payments over 5 000 000 in minor units to a merchant account are refused (TrueLayer's sandbox limit); GBP payouts over 100 000 000 (Faster Payments' £1M).

Markets, banks and the payer's limit per payment

Jeton

Jeton's Merchant API v2 on its own paths, under /jeton: a Jeton client swaps https://merchant-api-sandbox.jeton.com for this host's /jeton. The API is real, built from Jeton's public OpenAPI 3.1 (openapi.yaml) and its sandbox guide. Credentials are ignored: any Jeton-Api-Key is taken and names the merchant (its payments, payouts, accounts in 15 currencies and USDT, events and webhook address); Jeton-Timestamp, Jeton-Nonce and Jeton-Signature are not checked. Idempotency-Key is required on the money-moving POSTs and honoured (the same request replays with Idempotent-Replayed: true; another request under the key is idempotency_key_reused). Money is a decimal string; errors are application/problem+json with Jeton's codes. FX and transfers are not simulated.

• POST /jeton/v2/payments (200, checkout.url; the checkout expires after 15 minutes), GET /v2/payments, GET /v2/payments/{id}
• POST /jeton/v2/payouts (202; jeton_account by customer number, email or phone, completed inside the request; bank_account on sepa_instant or swift; crypto_wallet in USDT on TRX or ETH), GET /v2/payouts, GET /v2/payouts/{id}, POST /v2/payouts/requirements
• GET /jeton/v2/accounts, /accounts/{id}, /accounts/{id}/transactions, /payment-methods, /me, /events, /events/{id}
• The sandbox's simulator: POST /jeton/v2/simulator/payments/{id}/complete {"checkoutUrl"} (the test customer 4815162342 pays), POST /v2/simulator/accounts/{id}/deposits, GET /v2/simulator/counterparties (customer 4815162342, business 4455667788)
• /jeton/checkout/{token}: the hosted checkout. Log in with the Jeton account's email or phone (any password), approve the login in the Jeton app (drawn beside the page on a computer) or type its six-digit code, review, Pay; back to returnUrl. ?device=mobile|desktop forces either flow.
• GET|PUT /jeton-lab/portal/webhook?apiKey=… {"url", "enabled"} (lab only): the merchant portal's v2 webhook address. Without one, events stay in GET /events. POST /jeton-lab/portal/payments/{id}/refund: a refund made in the portal (Jeton's API has no refund; the payment reads refunded).

Webhooks carry the outcomes (payment.completed, .expired, .cancelled, .refunded, payout.completed, .failed), each an Event envelope, signed as Standard Webhooks (webhook-id, webhook-timestamp, webhook-signature: v1,…) with the published secret whsec_YmlzdHJvbWF0aGljLWxhYi1qZXRvbi13ZWJob29rLXNpbXVsYXRpb24=. A paid payment completes 1.5 s after the payer pays; a bank payout reaches its rail after 1 s and ends 2 s later; a crypto payout in 5 s.

The sandbox's magic payout destinations

Jeton accounts at the checkout (the lab's)

Lab rules

Limits (the lab's): a payment from about 1 to 50,000 euros' worth, a payout up to 25,000 (amount_below_minimum, limit_exceeded); a payout beyond the account's balance is insufficient_funds. Each fiat account opens with 100,000.00. The fees and these limits are the lab's; Jeton publishes neither.

AstroPay

AstroPay's Checkout (Partners API) and its OneTouch merchant API (wallet cashouts, Direct Withdrawal) on their own paths, under /astropay: an AstroPay client swaps https://partners-api-sandbox.astropay.com and https://onetouch-api-sandbox.astropay.com for this host's /astropay. The API is real where AstroPay's public guides document it (developers.astropay.com) and modeled where they do not: AstroPay's regulated-gambling and wallet-checkout sections are private (77 of 185 pages), so the payer's AstroPay user id on a deposit (deposit_user_id, from the public closed-loop guide), the checkout's 20-minute expiry, the payer's screens and the cashout API's error codes (AstroPay documents only their descriptions) are the lab's. Credentials are ignored: the Basic client id (or the lab's Bearer token) names the partner, Merchant-Gateway-Api-Key or Merchants-Backend-Api-Key the merchant; no Signature is checked.

• POST /astropay/v1/partners/oauth/token (Basic client_id:client_secret, grant_type=client_credentials; a 43199-second Bearer token)
• POST /astropay/v1/payments (method: CHECKOUT, requested_payment_method: ASTROPAY; PENDING with redirect_url; expires after 20 minutes), GET /v1/payments/{id}?method=CHECKOUT, POST /v1/payments/refund (full or partial; 412 PAYMENT_NOT_FOUND, INVALID_AUTHORIZATION_STATUS, REFUND_AMOUNT_EXCEEDED, PAYMENT_PROCESSING_ERROR), GET /v1/certificates. Currencies: USD, EUR, GBP, CAD, BRL, ARS, CLP, COP, MXN, PEN, UYU, INR.
• Callbacks (COMPLETED, EXPIRED, REJECTED) go to callback_notification, else the merchant's URL, signed with Partner-Signature (SHA256withRSA over requestId:timestamp:body) by the lab's published key; its certificate, serial 1A57C0DE20261111, is what /v1/certificates answers.
• POST /astropay/merchant/v1/cashout to a user id or a phone: APPROVED at once to an AstroPay user; PENDING to a phone with no account, CANCELLED after 24 hours (a phone ending 0077 signs up 30 seconds later: APPROVED). GET /merchant/v1/cashout/{id}/status, GET /merchant/v2/cashout/external/{merchant_cashout_id}/status.
• POST /astropay/merchant/v2/cashout/init (Direct Withdrawal; each country's required fields), GET /merchant/v2/cashout/{cashout_external_id}/status, GET /merchant/v1/cashout/payout/banks/{country}. CREATED, PENDING after a second, APPROVED (SPCD_1000-Txn successful) three seconds later. Brazil's staging CPFs: 12345678909 created, 22345678909 refused for its status.
• Cashout and withdrawal callbacks carry Signature, the hex HMAC-SHA256 of the body under the published secret bistromathic-lab-astropay-simulation-secret-key.
• /astropay/checkout/payment/{id}: AstroPay's checkout. The AstroPay account's phone number, the six-digit code sent by SMS (on a computer it arrives on the phone drawn beside the page), the confirmation, Pay; back to redirect_success_url, redirect_error_url or cancel_url. ?device=mobile|desktop forces either flow.
• GET|PUT /astropay-lab/merchant?app_id=… {"merchant_name", "callback_url"} (lab only): what AstroPay sets at onboarding. POST /astropay-lab/users {"phone"}: the phone signs up, and its PENDING cashouts are paid.

AstroPay users at the checkout

Direct Withdrawal countries

Lab rules (from 10.00, the amount's last two digits)

Brazil's betting ban (MP 1.394/2026) stops regulated gambling payments there; the lab still takes BRL and pays out by PIX.

CryptoProcessing (CoinsPaid)

CryptoProcessing by CoinsPaid's merchant API on its own paths, under /coinspaid: a client swaps https://app.sandbox.cryptoprocessing.com for this host's /coinspaid. The API is real, built from the public docs (docs.cryptoprocessing.com: an OpenAPI 3.1 block on every endpoint page, and the Postman collection). Credentials are ignored: any X-Processing-Key is taken and names the merchant; X-Processing-Signature must be there but is not checked. Validation messages, status codes and callbacks are CryptoProcessing's. Callbacks carry X-Processing-Key and X-Processing-Signature, the hex HMAC-SHA512 of the body under the published secret bistromathic-lab-coinspaid-simulation-secret.

• POST /coinspaid/api/v2/addresses/take (201): a deposit address for a user (foreign_id, end_user_reference, sender_type and sender_data are required, as MiCA has them), optionally converting deposits (convert_to). A new address each call; a merchant reuses one per user and currency.
• POST /coinspaid/api/v2/withdrawal/crypto (201, status: processing): to any address, with conversion from another balance (convert_to, amount or amount_to); sender and receiver data required.
• GET /coinspaid/api/v2/transactions/info by id, foreign_id (withdrawals) or txid: a JSON body as the docs send it, or the same as query parameters (a Worker cannot send a GET with a body).
• POST /coinspaid/api/payments/v1/requests (201): a payment request; its payment_link is the lab's hosted page (pick a currency, Proceed to payment, pay the address); callbacks processing, paid, failed, expired.
• POST /v2/accounts/list, /v2/currencies/list, /v2/currencies/rates, GET /v2/ping. Exchanges and instant withdrawals are not simulated.
• GET|PUT /coinspaid-lab/portal/callback?key=… {"url"} (lab only): the portal's callback URL for that key.
• /coinspaid/deposit?m=<key>&a=<address id>&amount=&cy=&return=: the deposit page a merchant shows (CryptoProcessing hosts none for addresses): the address, a real QR code (it opens the wallet on a phone), the network and the amount; the player's wallet drawn beside it on a computer. ?device=mobile|desktop forces either flow.

A deposit is seen 2 s after the wallet sends it (not_confirmed) and confirmed after 1.5 s per confirmation the currency needs, at most 9 s. One below the minimum deposit is cancelled; the wallet can also double-spend (cancelled) or never confirm. A withdrawal confirms after 3 s; to 0x000000000000000000000000000000000000dEaD it is cancelled as forbidden.

Currencies (the lab's rates in EUR)

No USDT: CryptoProcessing no longer lists it. Fiat for conversion: EUR, USD, GBP, CHF, SEK, NOK, DKK, PLN, CZK, HUF, CAD, AUD, NZD, JPY, TRY, BRL, MXN, ZAR, INR, ARS, AZN, BDT, CLP, CNY, IDR, KRW, MDL, MYR, NGN, PEN, PHP, THB, VND. Each merchant starts with 100000 EUR, 50000 USD, 2 BTC, 30 ETH, 100000 USDC, 50000 USDCS, 50000 EURCE, 500 LTC, 200000 TRX, 300 SOL, 20000 XRP.

Lab rules for withdrawals (the amount's last two decimals)

Shift4

Shift4's Gateway API (ex-SecurionPay), on the real host's own paths under /shift4: a client of https://api.shift4.com is pointed at <lab>/shift4 instead. Cards server to server with 3-D Secure 2, charges captured or authorized, captures, refunds, credits (funds to a card) and events. Every secret key is a merchant of its own. Only test mode is played.

Credentials are ignored: Shift4 authenticates with HTTP Basic, the secret key as the username and an empty password; the lab never refuses a key, it only tells merchants apart by it. Bodies may be form-encoded with bracketed keys, as Shift4 documents, or JSON, as its SDKs send. Webhooks are not signed, as Shift4's are not: Shift4 tells the receiver to take only the event's id and read the event back with GET /events/{id}, which the lab serves. Webhook URLs are set in Shift4's dashboard; the lab's stand-in is POST /shift4-lab/dashboard/webhooks with {"url": …} and the merchant's key.

• POST /shift4/tokens, GET /shift4/tokens/{id} — a card token (one use, 24 hours)
• POST /shift4/3d-secure — { enrolled, version, redirectUrl, token }: the payer at redirectUrl (/shift4/3d-secure/start/…, the issuer's challenge on the shared ACS page), then back at returnUrl?token=…&liabilityShift=successful|failed; the charge names the token. Unanswered for 10 minutes (modeled), the liability shift fails (abandoned)
• POST /shift4/charges — with card a token or the card itself; captured=false authorizes only; threeDSecure.external carries a merchant's own 3DS result. A charge on an enrolled card without a successful liability shift fails (authentication_required), as requireSuccessfulLiabilityShiftForEnrolledCard (default true) says
• POST /shift4/charges/{id}/capture — within 5 days, partial or full
• POST /shift4/refunds — partial or full on a captured charge; an authorization is released in full
• POST /shift4/credits — funds to a card (the token or the card); up to 25,000.00 (modeled, limit_exceeded above)
• GET lists and objects: /charges, /refunds?chargeId=…, /credits, /events (newest first, limit, created[gte] …, startingAfterId)

Events (CHARGE_SUCCEEDED, CHARGE_FAILED, CHARGE_CAPTURED, CHARGE_REFUNDED, REFUND_UPDATED, CREDIT_SUCCEEDED, CREDIT_FAILED) are POSTed as JSON to the dashboard's webhook URLs; Shift4 takes HTTP 200. A POST with an Idempotency-Key answers its first answer again for 24 hours (Idempotent-Replayed: true). Charges above 50,000.00 (modeled) fail with limit_exceeded.

Test cards (Shift4's own)

Any future expiry and any 3 or 4 digit CVC. A card number not listed is approved and not enrolled in 3DS. A card arriving as vault ciphertext is recognised by BabelPay's BIN and last-four headers; its CVC cannot be read, so the CVC-123 card approves then.

Lab rules

Real or modeled

• Real (dev.shift4.com, its OpenAPI description): the paths, the request and response fields, Basic auth with the secret key, form or JSON bodies, the error object and its types and codes, the 3-D Secure process (/3d-secure, redirectUrl, returnUrl with token and liabilityShift, the charge with the token), the test cards, idempotency, events and unsigned webhooks, the 24-hour token and 5-day capture windows.
• Modeled: the challenge's expiry, the charge and credit ceilings, the lab rules, the errors' wording on invalid requests, the issuer's page (the shared ACS page; the 3DS process is always a challenge), no customers, plans or subscriptions (charge a card or a token), disputes on the dispute cards (not raised).

PXP

PXP's Unity API (pxp.io, ex-PXP Financial: regulated gaming in 23 US states, the EU and Canada), on the real hosts' own paths under /pxp: a client of https://api-services.test.pxp.io is pointed at <lab>/pxp instead. Cards server to server with PXP's integrated 3-D Secure 2, authorisations, purchases, captures, refunds, voids and card payouts, on one transaction endpoint. Every client id is a merchant group of its own. Only the sandbox is played.

Credentials are ignored: PXP signs every request (Authorization: PXP-UST1 {tokenId}:{timestamp}:{HMAC}, an upper-case hex HMAC-SHA256 of timestamp, X-Request-Id, path and body under the token value, with X-Client-Id); the lab never checks the signature and tells merchant groups apart by the client id. Webhooks are signed as PXP signs them: X-Signature is the Base64 HMAC-SHA256 of X-Request-Id + X-Signature-Timestamp + the body, under the published simulation key bistromathic-lab-simulated-flow. Webhook URLs are set in PXP's Unity Portal; the lab's stand-in is POST /pxp-lab/portal/webhooks with {"url": …} and the merchant group's X-Client-Id.

• POST /pxp/api/v1/transactions — transactionMethod.intent Authorisation, EstimatedAuthorisation, Purchase, Verification, Payout or Refund; the card itself or a gatewayTokenId; threeDSecureData.authenticationId (PXP's own 3DS) or a third party's CAVV and ECI; psd2Data.scaExemption. Answers state (Authorised, Captured, Refused, Error), stateData (CRD codes) and a gateway token. A repeated merchantTransactionId answers the original when it succeeded and is processed again when it failed
• POST /pxp/api/v1/transactions/{systemTransactionId}/modifications — operation Capture, FinalCapture, Refund (partial or full, on a captured transaction) or Void (an uncaptured authorisation); each answers a new systemTransactionId
• GET /pxp/api/v1/transactions/{merchant}/{site}?merchantTransactionId=…|systemTransactionId=…&fundingType=Card — an array of zero or one transaction
• POST /pxp/api/v1/threedsecure/integrated/authentications, PUT …/{id}/browser-authentication, GET …/{id}/outcome, GET …/{id}/assessment — PXP's integrated 3-D Secure: frictionless, or PendingCustomerChallenge with acsUrl and challengeData; the payer posts creq to the ACS (the shared issuer page), which posts cres to the challengeCallbackUrl. Unanswered for 10 minutes, the challenge fails (U, reason 14)

Webhooks (eventCategory transaction: Authorised, Captured, Cancelled, Refunded, Refused TXN_RFU, Error TXN_ERR; authentication: the challenge completed) are POSTed as JSON to the portal's URLs; PXP retries 10 times within 10 seconds. A transaction above 50,000.00 is refused (CRD110), a payout above 25,000.00 too (CRD121), both modeled. An amount with more decimals than its currency is refused (CAR0010).

Test cards (PXP's own)

Any future expiry and any valid CVC. A card number not listed authenticates frictionless and is approved. A 3-D Secure test card charged without a successful authentication is soft declined (CRD180, SCA required) unless an exemption PXP grants applies. A card arriving as vault ciphertext is recognised by BabelPay's BIN and last-four headers.

Lab rules

Real or modeled

• Real (developer.pxp.io and its downloadable OpenAPI descriptions): the hosts and paths, the request and response fields, the PXP-UST1 signature and its headers, the states and CRD response codes, the error envelope and its published codes (CAR0003, CAR0004, CAR0005, CAR0006, CAR0010, GEN0008), idempotency by merchantTransactionId, the integrated 3-D Secure flow and its states, the 3DS and PSD2 test cards and amounts, the drop-in test cards, the webhook body and its signature, the 10-minute challenge window.
• Modeled: the state of an approved purchase (Captured) and payout (Authorised), the soft decline of an unauthenticated SCA card, the 3DS service's error codes, the capture window (7 days), the ceilings, the lab rules, the wording of validation details, the issuer's page (the shared ACS page), the webhook key's encoding (UTF-8 bytes), no DCC, no incremental authorisations, no pay-by-bank (SPEI, CVU, Bre-B, FlashFlow, Aeropay) and no in-store.

Volt

Volt's current ("Global") APIs on their own paths, under /volt: a Volt client swaps gateway.sandbox.volt.io (OAuth and the Global Payments API) and accounts.sandbox.volt.io (the Accounts API v2) for this host's /volt, and the hosted checkout (checkout.volt.io) is /volt/checkout. Credentials are ignored: any client id, secret, username and password get a token at POST /volt/oauth (the password grant, JSON or form), and the token names the merchant (its EUR, GBP and AUD Volt accounts with 1 000 000.00 each, its payments and beneficiaries). X-JWS-Signature is required on outgoing transactions and not checked; Idempotency-Key and X-Volt-Api-Version: 1 are required, and a key used before is 409 IDEMPOTENCY_CONFLICT, as Volt does. The API is real: built from Volt's public OpenAPI files (the Global Payments API on docs.volt.io, the Accounts API in github.com/volt-io/volt-io-accounts) and docs. The real banks' ids and limits, the lab's amount rules, the timings and the euro countries offered are the lab's. The legacy Gateway and Accounts APIs are not simulated.

• POST /volt/payments (X-Volt-Initiation-Channel: hosted; OPEN_BANKING_EU, OPEN_BANKING_UK, NPP_PAY_TO_AU), GET /volt/payments/{id}, POST /volt/payments/{id}/cancel, GET /volt/institutions, /institutions/{id}, /institutions/countries
• GET /volt/accounts, /accounts/{id}, /accounts/{id}/beneficiaries (whoever paid in during the last 12 months), POST /volt/accounts/{id}/transactions (PAYOUT, closed loop only; REFUND of an incoming transaction), GET /volt/transactions (?gatewayPaymentId=, sourceTransactionId, type[], …), /transactions/{id}, /account-holder-verifications/{id}, …/approve, …/reject
• /volt/checkout/{paymentId}?auth=… — the hosted checkout: the bank picker with search, PayTo's PayID or BSB (Australia), the summary, on a computer a real QR code to continue in the banking app (the phone is drawn beside the page; a real phone's camera works too), the bank's app or website, the sandbox's Synthetic Redirect page and Synthetic Embedded login (one-time code 123456), the status page, and back to the return URL. ?device=mobile|desktop forces either flow.

Notifications go to the request's communication.notifications.url, signed X-Volt-Signed (hex HMAC-SHA256 of body|X-Volt-Timed|version) under the published secret bistromathic-lab-volt-notification-secret: gateway notifications (User-Agent: Volt/1.0; PENDING, COMPLETED, FAILED with a detailedStatus), Volt Connect's payment_received and payment_not_received, and the Accounts API's outgoing_transaction_completed, outgoing_transaction_rejected and account_holder_verification_result_completed (Volt/2.0, X-Volt-Type). A payment completes 1.5 s after the bank approves and is RECEIVED into the Volt account 2 s later (an incoming GATEWAY_PAYMENT transaction; the payer is now a beneficiary); an outgoing transaction is PROCESSING after 1 s and COMPLETED 2 s later. A payment nobody finishes is ABANDONED_BY_USER after its validityPeriod.

Lab rules (any bank)

Markets, banks and the payer's limit per payment

D24 (Directa24)

D24's Deposits API and Cashouts API (v3) on their own paths, under /d24: a D24 client swaps https://api-stg.directa24.com for this host's /d24. The API is real (docs.d24.com, public): the bodies, statuses, error codes and notifications, and D24's own Mock PSP scenarios by amount. Modeled: the method limits and expiry times (the merchant account's, unpublished), the notification headers (X-Date, X-Login, Authorization, as D24's security guide says notifications are signed), and the payer's screens. Credentials are ignored: X-Login names the deposits merchant, the body's login the cashouts merchant; no Authorization or Payload-Signature is checked.

• POST /d24/v3/deposits (OneShot; X-Idempotency-Key honoured): ONE_SHOT with payment_info and redirect_url, or HOSTED when the payer's document, email or name is missing. GET /v3/deposits/{deposit_id}, GET /v3/payment_methods?country=. Errors as D24's API Codes: 201 BEAN_VALIDATION_ERROR, 300 USER_BLACKLISTED, 400 INVALID_AMOUNT (under USD 2), 401 PAYMENT_METHOD_NOT_FOUND (Boleto BL, retired 2024-12-23), 402 INVOICE_ALREADY_USED, 408 / 410 method limits.
• POST /d24/v3/refunds (a COMPLETED deposit; bank_account required: 804 MISSING_BANK_ACCOUNT), GET /v3/refunds/{refund_id}: PENDING, DELIVERED, then COMPLETED or CANCELLED.
• Deposit and refund notifications: {"deposit_id"} / {"refund_id"}, with X-Date, X-Login and Authorization: D24 <hex HMAC-SHA256 of X-Date + X-Login + body> under the published deposits API Signature d24-lab-deposits-signature-0a4c19e2b7.
• POST /d24/v3/cashout (each country's validations: Pix keys 10000–10003 and banks in Brazil, a CLABE in Mexico, Bre-B keys 20000–20003, Efecty 10003, Nequi, Daviplata and banks in Colombia), POST /v3/cashout/status, DELETE /v3/cashout/cancel, GET /v3/banks?country=. PENDING (0), DELIVERED (4) a second later, then COMPLETED (1), REJECTED (3) or CANCELLED (2). Notifications are form posts with control = upper-case HMAC-SHA256 of Be4<external_id>Bo7 under the published cashouts API Signature d24-lab-cashouts-signature-5f81d03c6e.
• /d24/v1/checkout/{token}: D24's checkout. Pix: a real BR Code as QR and "Copia e Cola", the bank app beside it. SPEI: the CLABE. OXXO and Efecty: a cash voucher with a real Interleaved 2 of 5 barcode and the lab's counter. PSE: the bank picker, then online banking with the bank app's dynamic key. ?device=mobile|desktop forces either flow.
• GET|PUT /d24-lab/merchant?x_login=… {"merchant_name", "notification_url"} (lab only): the Merchant Panel's settings.

Methods

D24's Mock PSP: the amount's leading digits (trailing zeros ignored)

Cashout bank codes

Brazil's betting ban (MP 1.394/2026) stops regulated gambling payments there; the lab still takes BRL and pays out by Pix.

Zota

Zota's (ex-Zotapay) MG Deposit API 1.0 and MG Payout API 1.1 on their own paths, under /zota: a Zota client swaps https://api.zotapay-sandbox.com for this host's /zota. The API is real, from Zota's public docs (docs.zota.com): the paths, the fields and their lengths, the {code, message} refusals (400 missing arguments, bad request, endpoint currency mismatch, timestamp too old; 404 not found; 409 order already created), the order statuses and the SHA-256 signatures. Each country's methods, the limits, the payment form's screens and the payer's account in a deposit's extraData are modeled: Zota sets them per merchant endpoint and does not publish them. Credentials are ignored: no signature is checked, and any MerchantID is the lab's one merchant.

• POST /zota/api/v1/deposit/request/{EndpointID}/: an order, CREATED, and its depositUrl, Zota's payment form (/zota/api/v1/deposit/init/{orderID}/), where the payer picks a local bank, the country's QR code, an e-wallet or mobile money. An order nobody submits is DECLINED after 20 minutes.
• GET /zota/api/v1/query/order-status/?merchantID&merchantOrderID&orderID&timestamp&signature (a timestamp older than 15 minutes is refused); GET /zota/api/v1/query/current-balance/.
• POST /zota/api/v1/payout/request/{EndpointID}/ to a local bank account (customerBankCode, customerBankAccountNumber, customerBankAccountName; a wallet's or mobile money's code and number): AUTHORIZED, PROCESSING a second later, APPROVED three seconds after that. The Payout Form ("none") is not enabled.
• The payer goes back to redirectUrl with status, orderID, merchantOrderID and signature = SHA-256(status + orderID + merchantOrderID + secret); every final status is POSTed to callbackUrl with signature = SHA-256(EndpointID + orderID + merchantOrderID + status + amount + customerEmail + secret). The lab's published secret is BISTROMATHIC-LAB-ZOTA-SIMULATION-SECRET.
• On a computer the payer's phone is drawn beside the form (the bank app's approval, the camera on the QR code, the wallet's push); the QR code is real: a phone camera pointed at it pays on the phone while the form follows. ?device=mobile|desktop forces either flow.
• GET|PUT /zota-lab/endpoints/{EndpointID} {"merchant_name"} (lab only): the merchant's name on the form, as Zota sets it at onboarding. Another EndpointID than the published ones takes the currency of its first order.

Markets and published endpoints (deposit / payout)