Embedded Fields (/platform/embedded) → tokenize card → Payment Gateway (Sale, Auth, Capture, Void, Refund, Verify). Test environment only. — ← Back to Index
⚠️ This page sends your Security Key as a Basic-Auth header directly from the browser, which is fine for local sandbox testing but is not how a production integration should work (the Sale call belongs on your server, never in client-side JS). Never point this page at production credentials.
1 Credentials
SANDBOX
V1 — the current, frozen SDK.
V2 is only deployed on Snapshot as of 2026-09-22 (confirmed by inspecting the live Snapshot demo directly) — the V2 button is disabled on Sandbox/QA until it rolls out there too. This restriction is expected to lift for all environments later.
Pre-filled with the sandbox MID/key on file. API host: https://api-test.qualpay.com. Fields stay editable if you need to override.
ACH MID Reference
Reminder of which MID to use for testing with vs. without ACH enabled, per environment. Blank/greyed rows mean we don't have a security key with working API access for that MID yet (tabled — see the Wendy ask on the Weekly Product Meeting Agenda). Snapshot's default MID does not have ACH; Sandbox and QA's default MIDs do.
Environment
Variant
MID
Security Key
2 Get Transient Key
GET /platform/embedded — issues a single-use key (expires in 12h) used to load the card-entry iframe.
3 Enter Test Card (tokenize)
Loads Qualpay's hosted card-entry iframe — Embedded Fields itself only ever tokenizes (optionally with a $0 verify); it has no "Sale" mode of its own. Tokenize returns a one-time card_id for step 4 — no card data touches this page. Tokenize + Verify immediately follows the tokenize with a $0 /pg/verify issuer check. Tokenize with PG (Payment Gateway) request immediately follows the tokenize with whichever transaction type is currently selected in step 4 (defaults to Sale) — not available for Capture/Void/Refund, which act on an existing pg_id instead of a fresh card.
Sandbox test cards / CVV / amounts
Card
Number
Visa (debit)
4111 1111 1111 1111
Visa (consumer credit)
4212 2222 2222 2222
Mastercard (consumer credit)
5544 6666 6666 6664
Discover
6011 0011 2211 1117
Amex
3714 496353 92376
Any future expiration date and any 3-digit CVV work. The full amount-triggered response table is in step 4's scenario picker below. Full list in Qualpay's test conventions doc.
3b Or: Pay with Google Pay
Alternative to steps 2–3. Tokenizes via Google directly and sends the result as payload_google_pay instead of card_id.
⚠️ Google Pay's JS API requires a secure context — it will not initialize over file://. Serve this page via https:// or http://localhost to test this button. It also needs a real Chrome browser signed into a Google account with a payment method (Google's own TEST environment still requires this — it just won't move real money).
3c Or: Pay with Apple Pay
Alternative to steps 2–3. Tokenizes via Apple directly and sends the result as payload_apple_pay instead of card_id.
⚠️ Apple Pay only works in Safari (not Chrome) and only over a verified HTTPS domain — it won't show up here at all otherwise. Make sure you're signed into the sandbox tester Apple ID with a test card in Wallet.
Before first use: Start the local proxy and tunnel (2 Terminal tabs)
Tab 1 — Proxy
cd "/Users/lisa/Documents/Claude for Qualpay/Apple Pay Local Tools"
python3 apple_pay_proxy.py
Tab 2 — Tunnel
cd "/Users/lisa/Documents/Claude for Qualpay/Apple Pay Local Tools"
./cloudflared tunnel run apple-pay-proxy
Both must be running before clicking the Apple Pay button below. Full steps: see apple-pay-test-quick-steps.md
Merchant validation health check — pings the mTLS proxy/tunnel (apple-pay.lisaanderson.biz) with Apple's real validation-session URL, without needing Face ID/Touch ID. Useful for confirming the proxy + tunnel + certificate chain is up before doing a full demo run.
4 Run Transaction
Transaction type — Sale and Auth fund off a card/wallet from step 3/3b/3c; Capture, Void, and Refund act on an existing transaction's pg_id instead (no card needed); Verify is a $0 issuer check (card_id only). Endpoints confirmed from Qualpay's API reference.
Authorizes + captures in one step.
Advanced: Payment Profile ID
Optional, all transaction types. Per Qualpay's API reference: "Explicitly identifies which Payment Gateway profile should be used for the request." 20-digit numeric. Leave blank to use the account's default profile. See Qualpay Manager → Payment Profiles for the IDs available on this MID.
Quick scenarios — sets the amount to trigger a specific sandbox response. Works the same regardless of whether you funded with a card, Google Pay, or Apple Pay, since Qualpay's sandbox drives these off amt_tran at the gateway, not the payment method.
Per Qualpay's test conventions. Partial approval also sets a partial_auth flag so the gateway can return a reduced amt_tran.
Only have it in a curl response? Paste it here to extract
Payment Gateway calls are CORS-blocked from the browser (see warning above), so a Sale/Auth's real pg_id usually only shows up in Terminal after you run the generated curl command, not in this page's log. Paste that JSON response here to pull pg_id out of it automatically.
Add line items + tax (optional, Level 2/3-style)
Best-effort mapping to Qualpay's documented Level 2/3 fields (line_items as a JSON array, amt_tax). Line-item enhancement typically needs to be enabled on your MID to actually qualify for lower interchange — this is here for demoing the request shape, not a guarantee Qualpay's sandbox will echo it back differently. Adding a line item overrides the Amount field above with the computed total.
DescriptionQtyUnit cost
Line items + tax$0.00
Advanced: link to an existing subscription
If you already have a Recurring Billing subscription_id from Qualpay Manager, pass it through here to tag this sale against it. This page doesn't create subscriptions/plans itself — see step 5 below for the customer-vault-based recurring simulation instead.
POST /pg/sale using whichever payment credential you captured in step 3, 3b, or 3c.
Last gateway call
Request → /pg/sale
Response
5 Save to Customer Vault & Run a Recurring-Style Charge
Demos the "no wallet/card entry on repeat charges" pattern: save the tokenized card to Qualpay's Customer Vault (POST /platform/vault/customer) once, then reuse the returned customer_id on later /pg/sale calls instead of card_id/payload_apple_pay/payload_google_pay. This is a lightweight simulation — a real recurring schedule also needs a Plan + Subscription set up via the Recurring Billing API or Qualpay Manager, which is out of scope for this page.
⚠️ Vaulting requires a persisted card_id (from step 3's Embedded Fields tokenization). Apple Pay/Google Pay tokens are single-use wallet payloads, not a stored card — vaulting straight from a wallet isn't part of Qualpay's documented flow. If you funded via 3b/3c, this step stays disabled unless the /pg/sale response in the log below happens to hand back a reusable card_id of its own.
Customer ID: — every click below runs a fresh /pg/sale with customer_id set instead of a card/wallet payload, at the amount currently in step 4, tagged with an incrementing purchase_id.