Skip to content
API DocsDocs

Going to Production

Everything you need to switch from sandbox to production

6 min readUpdated Mar 26, 2026

This guide covers everything required to move from sandbox testing to live production payments.

#Environment URLs

EnvironmentBase URLPurpose
Sandboxhttps://sandbox.api.exirom.com/apiTesting and development
Productionhttps://api.exirom.com/apiLive payments

Both environments use identical API contracts. All endpoints, request/response schemas, and webhook formats are the same.

TLS requirement: All API communication must use TLS 1.2 or higher. Connections using older TLS versions are rejected.

#Credentials

#Obtaining Production Credentials

  1. Contact the Exirom operations team to request production credentials
  2. You'll receive a Merchant Key and Merchant Secret for production
  3. These are different from your sandbox credentials — sandbox tokens do not work in production

#Credential Management

  • Store credentials in environment variables or a secrets manager (AWS Secrets Manager, HashiCorp Vault, etc.)
  • Never hardcode credentials in source code or commit them to version control
  • Use separate credentials per environment (sandbox, staging, production)
  • Rotate credentials immediately if they are exposed

#Token Caching

Tokens are valid for 30 days. Cache and reuse tokens — do not authenticate per request. Refresh proactively at day 29 rather than waiting for a 401.

If a 401 Unauthorized is received, discard the cached token, re-authenticate, and retry the original request once.

→ See Authentication Flow for the full token lifecycle and error reference.

#Webhook Configuration

#Endpoint Requirements

Your webhook endpoint must:

  • Accept POST requests with JSON body
  • Respond with 200 OK within 10 seconds
  • Be publicly accessible (no localhost, no VPN-only)
  • Support HTTPS (TLS 1.2+)

#Verify Signatures

Always verify the X-Checksum header in production. See the Webhook Best Practices guide.

#Test Your Endpoint

Before going live, verify your webhook endpoint handles:

  • Successful payment callbacks
  • Failed payment callbacks
  • Duplicate deliveries (same callback twice)
  • Out-of-order callbacks
  • APM callbacks with apmType parameter
  • Invalid/missing X-Checksum (should reject)

Use tools like ngrok or webhook.site during development to inspect callback payloads.

#Monitoring & Alerting

#Key Metrics to Track

MetricAlert ThresholdWhy
Payment success rate< 90% over 15 minIndicates PSP issue or config problem
Avg response time> 5 secondsNetwork or processing degradation
Webhook delivery failures> 5% in 1 hourYour endpoint may be down
401 Unauthorized rateAny spikeToken expired or credentials rotated
Decline code 29 (Merchant Not Active)Any occurrenceAccount deactivated — contact support immediately

#What to Log

For every API call, log:

  • requestId — your unique identifier for correlation
  • transactionId — Exirom's identifier (from response)
  • traceId — included in error responses for Exirom support
  • HTTP status code
  • transactionStatus and declineCode
  • Timestamp

When contacting Exirom support, always include the transactionId and traceId. This dramatically speeds up investigation.

#PCI DSS Compliance (Card API Only)

If you use the Card API (direct card data collection), you are in PCI DSS scope:

IntegrationPCI Requirement
Card API (S2S)PCI DSS Level 1 (SAQ-D)
Hosted Payment PagePCI DSS Level 4 (SAQ-A) — minimal scope
Tokenized paymentsDepends on how tokens were originally obtained

If using Card API:

  • You must complete SAQ-D self-assessment or Level 1 audit
  • Card data must be transmitted over TLS 1.2+ only
  • Never log full card numbers — use masked format (4111********1111)
  • Never store CVV after authorization

If PCI scope is a concern, consider using the Hosted Payment Page instead — it handles card data on Exirom's PCI-certified infrastructure.

#Pre-Launch Checklist

#Configuration

  • Production credentials obtained and stored securely
  • API base URL points to https://api.exirom.com/api (not sandbox)
  • Webhook endpoint is HTTPS and publicly accessible
  • Webhook signature verification is enabled
  • Correct mid / accountId for production

#Code Quality

  • Idempotency implemented (unique requestId per transaction, reused on retry)
  • Webhook deduplication in place
  • Error handling covers all decline codes
  • Token caching with proactive refresh
  • 401 retry logic implemented
  • Polling fallback for missed webhooks

#Testing

  • Full payment flow tested in sandbox (initiate → 3DS → webhook → fulfill)
  • Refund flow tested
  • Payout flow tested (if applicable)
  • Webhook failure/retry tested
  • All supported currencies tested

#Operations

  • Monitoring dashboards set up
  • Alerting configured for key metrics
  • On-call process defined for payment failures
  • Exirom support contact saved (for escalation)
  • Settlement process confirmed with Exirom operations team

#Sandbox vs Production Differences

AspectSandboxProduction
Card numbersTest cards only (4111...)Real cards
Money movementNo real chargesReal money
PSP responsesSimulatedReal PSP processing
Webhook timingNear-instantDepends on PSP (1s–30s typical)
3DS challengesSimulated challenge pagesReal bank 3DS pages
CredentialsSandbox key/secretProduction key/secret

Important: Sandbox tokens, transaction IDs, and card tokens are not valid in production. Do not attempt to use sandbox data in the production environment.

#API Health & Support

If you suspect an outage or degraded performance, contact the Exirom support team. Include:

  • Affected transactionId(s) and traceId(s) from error responses
  • Time range and approximate volume of affected transactions
  • Your mid

Contact: support@exirom.com — or your assigned account manager

For active production failures, mark your ticket as P1/Critical for expedited response.

AlertThresholdAction
Payment success rate< 90% over 15 minCheck PSP status, contact support
Webhook failures> 5% in 1 hourVerify endpoint health
Decline code 29Any occurrenceContact support — account may be deactivated
401 spikeSudden increaseToken expired or credentials rotated

#See Also

Was this helpful?