Go live safely

Test and live mode are separate environments. Enabling live mode is not a key replacement inside an otherwise shared integration: keys, resources, webhook endpoints and operational ownership must all be reviewed deliberately.

Before requesting live access

Complete the testing and security matrix and confirm that your integration:

• creates every order and Checkout Session from trusted server data;
• uses a stable idempotency key for retryable creation and financial mutations;
• fulfills only from verified terminal events;
• supports expiration, cancellation, duplicate events and delayed confirmation;
• gives customers a manual-transfer fallback when a browser wallet is unavailable; and
• has a support path for wrong-network, below-minimum, late and overpaid transfers.

Paybytoken may require business verification and product review before live credentials or payment methods are enabled. Test-mode eligibility never implies live-mode eligibility.

1. Create live credentials separately

Store sk_live_... in the production secret manager. Do not rename a test variable and leave its value in place, copy a key into a frontend deployment, or use one unrestricted key across every service.

Use a restricted key where its exact permissions are sufficient. Record the owner, runtime and rotation procedure for each production credential.

PAYBYTOKEN_SECRET_KEY=sk_live_...
PAYBYTOKEN_WEBHOOK_SECRET=whsec_...

Deploy secrets through your platform's secret mechanism, not a committed .env file. Confirm that application logs redact bearer keys, webhook signatures, embedded client secrets and complete one-time payment addresses.

2. Recreate live configuration

Review live mode in the Merchant Portal and recreate configuration rather than assuming test data was copied:

• checkout display name, logo, brand and action colors;
• enabled payment methods, chains and stablecoins;
• payout destinations and operational limits, when used;
• team access and least-privilege API keys; and
• one live webhook endpoint with the required event subscriptions.

Use token and asset discovery in live mode. Contract addresses, chain IDs, minimums, fees and availability can differ from test mode and must not be carried over from fixtures.

3. Register the production webhook

Use a public HTTPS URL dedicated to Paybytoken events. Store the returned live signing secret immediately and verify the exact raw body before JSON parsing.

Send a test event to validate networking and signature handling, then verify a real test-mode payment flow separately. webhook_endpoint.test confirms delivery mechanics only; it is never payment proof.

Your handler should:

1. verify the timestamped signature;
2. insert the Event ID under a unique constraint;
3. return 2xx only after durable acceptance;
4. process fulfillment idempotently; and
5. retrieve canonical resource state if delivery order is ambiguous.

Keep the previous secret during the documented overlap window when rotating. Remove it only after previous_secret_expires_at and after every receiver has the new value.

4. Verify browser boundaries

For hosted checkout, verify the production success and cancel URLs. For embedded checkout:

• set allowed_origin to the exact production origin;
• require HTTPS;
• allow the checkout host in frame-src and the API in connect-src;
• confirm that preview deployments create their own test Sessions; and
• ensure client_secret exists only in memory on the matching page.

For custom checkout, keep the Session CSRF token on your server and confirm the selected token from an authenticated server route. Never let the browser choose the destination address, contract or atomic amount.

5. Run a production smoke test

Start with the smallest permitted live amount and one enabled chain. Use a wallet you control and record:

• merchant order, Checkout Session and Payment Intent IDs;
• the Event ID and webhook delivery ID;
• transaction hash through the authenticated resource response; and
• timestamps for creation, detection, confirmation and settlement.

Verify the customer return experience, signed event processing, merchant balance movement and any refund or support action relevant to your product. Do not use browser completion as the pass condition.

6. Define monitoring and ownership

Alert on sustained webhook failures, pending payments beyond expected chain finality, payout or withdrawal failures, unapplied Payment Request funds and reconciliation drift. Dashboards should link to safe resource IDs and request IDs without exposing secrets.

Document who can:

• rotate API and webhook secrets;
• change checkout branding or enabled payment methods;
• retry failed webhook deliveries;
• approve refunds or investigate payouts; and
• contact Paybytoken with resource and request IDs.

Rollout checklist

• Production business access is approved.
• Live key is stored only in the production backend.
• Live webhook endpoint and signing secret are configured.
• Live branding, chains and assets were reviewed.
• Hosted URLs or embedded exact origin and CSP are correct.
• Duplicate, delayed and out-of-order events are safe.
• One minimum-value live payment completed end to end.
• Alerts and an operational owner exist.
• Rollback disables new checkout creation without deleting financial history.

After launch, use the troubleshooting guide for customer-facing failures and the Events and webhook delivery inspector for diagnosis.