Skip to main content

Go-live checklist 🧶

Direct Payment API
Technical Author Note

This page should cover, once finalized - this will be removed once the wues

  • Pre-launch checklist — swapping test keys for live keys, pointing webhooks at production and verifying signatures, confirming idempotency keys on payment-creating requests, and a full real-card test end-to-end (including a refund).
  • Compliance — the PCI self-assessment required for the chosen integration path.
  • What changes between environments — that only the keys and the money differ; the API surface is identical.

Use this checklist when taking your Direct Payment API integration live.

The PAYSTRAX Gateway sandbox and production environments are designed to function as similarly as possible. Switching between them is primarily a matter of swapping your credentials and base URL.

If you are a developer, or had a developer perform the integration for you, work through the following items before going live.

Set the API version​

Confirm the correct API version is configured and your integration isn't relying on a default.

Open points

  • The API version is sent as a header in outbound calls using X-Pop-Api-Version-Payment. Confirm the correct version is set and that your integration is not relying on a default.
  • Where is the API version declared in outbound webhook notifications — is there a header equivalent to X-Pop-Api-Version-Payment?
  • Is the notification API version set independently from the payment API version, or does it inherit from the connector configuration?
  • What is the process for syncing versions between the Direct Payment API and the Notification API when a version upgrade is needed?

Handle edge cases​

Use the PAYSTRAX test values (TODO: add link) to replicate various states and responses.

Beyond these, test your integration with:

  • Incomplete data
  • Invalid data
  • Duplicate data — retry the same request to observe the behaviour

Also have someone outside your development team test the integration, particularly someone who is not a developer.

Review your API error handling​

Do not wait until go-live to discover gaps in your error handling. Make sure your code handles every possible error type (TO ADD LINK), including those that should never occur in normal operation.

When testing, pay attention to what your users see. A card decline is a different situation from a backend error, and the message shown to the user should reflect that distinction.

Review your logging​

Log all significant request and response data on your side. Do not rely solely on PAYSTRAX-side logs — if your server cannot reach the PAYSTRAX API or there is a credentials issue, that request may not be recorded externally.

Regularly review your logs to confirm they capture what you need and do not store anything sensitive, such as raw card numbers, CVV values, or personally identifiable information.

Ensure you are not relying on sandbox objects​

Objects created in the sandbox environment are not usable in production. When recreating necessary objects in production, use the same identifier values — not just the same names — to ensure your code continues to work without modification.

Receive production credentials from PAYSTRAX​

Between TEST and PROD, only credentials, the connector, and the money are real — the API shape stays the same. Confirm you have received all of the following from Paystrax before proceeding:
  • Production API keys
  • Production X-Integrator-ID
  • Production connector configuration

Open points

  • Besides the base URL and API keys, which identifiers need to be swapped between TEST and PROD — is it only the X-Integrator-ID, or are there additional identifiers?
  • Who provides the PROD credentials and X-Integrator-ID — is this triggered by the merchant, or does Paystrax issue them automatically at a certain point in onboarding?

Swap sandbox base URL and tokens for production equivalents​

Replace all sandbox base URLs and tokens in your configuration with their production equivalents. Verify no sandbox values remain hardcoded anywhere in your codebase or configuration files.

Enable tokenization​

Since Direct Payment API transmits card data through your own systems, tokenization is essential — not optional — for production. Ensure it is active so that raw card numbers and CVV values are never stored or transmitted through your systems beyond the point of tokenizing them.

Open points

  • Does the merchant enable tokenization on their side, or does it require Paystrax to activate it at the account or connector level?
  • Is there a specific configuration step or request process required before going live?

Register and verify your production webhooks​

Point your webhooks at your production HTTPS endpoint and verify that signature verification is in place. Also confirm your production endpoint:
  • Handles delayed webhook notifications
  • Handles duplicate webhook notifications
  • Does not require event notifications to arrive in a specific order

Open points

  • Should I also subscribe to notifications?
  • What is the signature verification mechanism used by the Gateway in production webhook notifications, and where is it documented?

Run an end-to-end test in production including a refund​

Before opening to real users, run at least one full transaction flow in production — payment, confirmation, and refund — to verify the integration is functioning correctly end to end.

Complete your PCI self-assessment (SAQ D)​

Because Direct Payment API involves building your own card input form and transmitting card data directly to the PAYSTRAX API, your integration falls under SAQ D — the most extensive PCI self-assessment tier, covering the full range of PCI DSS requirements for systems that handle cardholder data directly.

Open points

  • Should Paystrax provide a reference document or checklist to help merchants work through SAQ D requirements specifically?