Reference Checkout TEST ONLY

The Payment Element, and the rules worth knowing before you wire production.

Integrator hard rules (do not skip)

Amount: named on the intent by your server. Sending one when confirming is refused with parameter_unknown, not ignored.
IP on charge: not a body field, request peer only. The Element confirms from the browser, so the peer is the buyer. A charge you build server-side records your egress IP. Proxying /check? Set body ip to the shopper.
PAN: never in your page. The Element keeps it in our iframe. Building a charge yourself means tokens only (ev: or wp:v1:); raw digits are rejected.
3DS: runs inside the frame. Driving it yourself, resubmit only three_ds.session_id, never client cavv/eci, and never alongside a wallet.
Idempotency-Key: required on the intent; stable per order, not a new UUID per click.
/check is not pre-approval: the charge re-runs the full engine. risk_decision_token only rejects mismatches.
Device signals: the Element attaches them. They fail open, so an empty signal still charges and looks like a healthy integration.
bin + last4 on /check so the decision token can bind the card.
Keys: pk_ in the browser with allowed domains set; sk_ never here. Merchant and mode come from the key, not the body.
Outcomes: onSuccess with succeeded or processing, and onError with card_declined. Never show a raw fraud reason to a buyer.
Do not fulfil on processing. Wait for the charge.succeeded webhook. The buyer may close the tab.
Server-derived (ignored if you send them): charge IP, is_mit, is_new_card, whether 3DS really happened.

Canonical list: 27-integration-hard-rules.md. View Source for what this page deliberately does not contain.

Your test keys not set

Checkout

Card fields, wallets and the 3-D Secure challenge are all inside this frame. Test cards: 4111 1111 1111 1111 approves, and so do the other sandbox test numbers in the testing guide. A decline needs an amount under 1.00, which this fixed-amount demo cannot produce. The same card at the same amount within 20 minutes is refused as a duplicate, so switch cards between tries. Any future expiry, CVV 123.

The browser half, in full

// your server: POST /v1/payment_intents (sk_) -> { client_secret } const wp = WorthyPayments('pk_test_…'); wp.mountPaymentElement('#payment', { clientSecret, onSuccess: (r) => { /* succeeded | processing */ }, onError: (e) => { /* card_declined, element stays mounted */ }, });

What runs where

In the frame (not your page): card entry, encryption, wallets, device signals, the 3DS challenge.

On our servers, always: pre-screen, scoring, device intelligence, the 3DS decision, the block gate. On every charge, with or without a decision token.

Derived server-side (body ignored if you send it): charge IP, is_mit, is_new_card, whether the 3DS cryptogram is real.

In your page: the mount call and your own UI. That is all, and it is the point.

Before production

Allowed domains must be set on the publishable key (Settings → Developers → API keys), or the frame renders blank. Update the list on the key without rolling the secret. Parent pages must be https://. http://localhost and http://127.0.0.1 are the local exception.

Verify the charge.succeeded webhook signature and fulfil from it, not from onSuccess.

Console. The flow logs here.