Test and production share one base URL. The environment is selected by the credentials and the Brand ID you send, not by the host you call, so going live is a matter of configuration and approval rather than re-pointing your integration.

Credentials

Production credentials can be issued for controlled production testing before a merchant is fully live. A merchant go-live additionally depends on completing the applicable onboarding and KYC requirements.

The bearer token is self-service: generate it in the Developers section of the dashboard. The S2S token is not. It is issued by Precium to qualifying merchants only, because submitting clear PAN data puts the integration in PCI DSS SAQ-D scope. Request it well before you need it, in both environments.

Low-value production testing MID

A low-value production testing MID is a production configuration used to validate end-to-end behaviour against real money, including reconciliation and settlement.

Throughput and IP allow-listing

The default limit is 10 transactions per second, per IP address.

Before launch, send Precium:

• the production IP addresses that will call the API,
• the production IP addresses that will receive webhooks,
• the transactions per second you need.

Those addresses are allow-listed and capacity is provisioned against the agreed figure. Traffic from an address that has not been submitted, or above the agreed rate, will be rate limited.

Merchant onboarding inputs

Onboarding requirements depend on the merchant and its risk profile. It starts with company registration and ownership information, and additional KYC and beneficial-owner information is required before cross-border settlement, with enhanced due diligence for higher-risk merchants.

For the acquiring-bank MID application, Precium may also request operational and risk information:

• average delivery time,
• historic chargeback ratio,
• historic refund ratio,
• forecast transaction volume.

Pre-integration testing

Precium can provide Postman recipes once the payment-feature checklist is complete. Dashboard access and API credentials are issued when the environment is provisioned.

Checklist

• Use the S2S token only for requests carrying clear PAN data, and the bearer token for everything else.
• Store Brand IDs per merchant processing configuration, not one per partner. A merchant with two MCCs has two Brand IDs.
• Implement the 3DS hand-off exactly as returned. The ACS value is not a plain redirect URL. See Completing a 3D Secure authentication.
• Send amounts in cents, and at least ZAR 1.00 for anything that must settle.
• Send real customer and cardholder data wherever it is available.
• Verify webhook signatures against the raw request body.
• Treat webhooks as the state-change mechanism and GET /purchases/{id}/ as a current-state lookup.
• Agree TPS and submit production API and webhook IPs for allow-listing.
• Reconcile on gateway_transaction_id, keeping RRN, authorisation code and amount as secondary data. See Reconciliation files.
• Release authorisation holds you do not intend to capture.
• Confirm the merchant’s card schemes, international-card rules, descriptor and settlement schedule.