Testing & going live

Test environment

Your Govifi representative can point your payment account at the processor’s sandbox, where payments authorize but no money moves. Use sandbox test cards (any future expiry, any CVV):

Number	Behavior
4111 1111 1111 1111	Visa — approves
5555 5555 5555 4444	Mastercard — approves
4000 0000 0000 0002	Declines (card_declined)

For ACH in sandbox, any valid-format routing/account number is accepted.

Pre-launch checklist

• Cognito admin token is server-side only — not in browser bundles, mobile apps, or repository history.
• Origins registered — every origin that renders the component is in your account’s allowed_origins.
• Fulfillment is webhook-driven — checkout_session.completed with a verified signature, idempotent on webhook_id.
• Webhook endpoint returns 200 fast and handles retries.
• success_url validates — treat the redirect as UX, the webhook as truth.
• Fees come from feequote — no client-side fee math.
• Declines are handled — payment.error with recoverable: true lets the customer retry in place.
• Session expiry is handled — on session.expired, mint a new session.
• SRI hash pinned if loading from the CDN.
• Apple Pay domain verified (only if you offer Apple Pay) — the domain that renders the component must serve /.well-known/apple-developer-merchantid-domain-association and be registered with the merchant account. The hosted checkout serves this file automatically; if you embed the component on your own domain, host the same file there too. Until the domain is registered, the Apple Pay button stays hidden (the SDK preflights the registered domain and hides it on mismatch).

Switching to production

Production uses the same API surface with your live processor configuration. Use your production Cognito admin token, update allowed_origins for your production domains, set the production callback_url, and re-fetch the production signing secret. Nothing in your integration code changes.