Production Go-Live Guide
This guide walks you through every step required to move your Aurora integration from the sandbox environment to the production environment. Work through each section in order — skipping steps increases the risk of issues after launch.
Do not move to the production environment until you have completed end-to-end testing in the sandbox environment. You must receive a sign-off from your Aurora integration contact. Production environment transactions are real and are immediately billable.
Production Readiness Checklist
Use this checklist to confirm your integration is ready before requesting Production access.
Integration Completeness
| Checklist Item | Notes |
|---|---|
| All payment flows tested end-to-end in the sandbox environment. | Including success, decline, and edge cases. See the Testing Scenarios Guide. |
| Refund and void flows tested | Both full and partial refund scenarios. |
| Token refresh logic implemented | Tokens must never expire mid-session for end users. |
| Idempotency keys used on all mutating requests | Prevents duplicate charges on network retries. |
| Error handling covers all documented error codes | User-facing messages must not expose raw error codes or stack traces. |
| Load testing completed | Coordinate with Aurora before running load tests. See the Testing Scenarios Guide. |
Code and Infrastructure
| Checklist Item | Notes |
|---|---|
| Production credentials stored in a secrets manager | Not in code, .env files committed to version control, or CI/CD logs. |
| All sandbox URLs replaced with Production URLs | Search your codebase for "uat.arise.risewithaurora.com" and replace with "arise.risewithaurora.com". |
| Logging excludes card information, CVVs, and full PANs | Log transaction IDs and error codes only. |
| HTTPS enforced on all endpoints that touch payment data | No mixed-content or HTTP fallbacks. |
| Timeout and retry policies configured | Recommended: 30s timeout, 3 retries with exponential backoff. |
Security Review and Compliance Checks
PCI-DSS Compliance
Aurora's payment solutions are designed to keep your integration out of PCI-DSS scope for card data. Confirm the following before launch:
- Card numbers, CVVs, and expiry dates are never transmitted through your servers.
- POS Integration: Your point-of-sale system uses Aurora's certified card readers that handle card data securely and never expose it to your application layer.
- Aurora Elements: Your frontend loads Aurora Elements via the official script tag — do not self-host or bundle it.
Contact your Aurora integration contact to receive Aurora's current PCI-DSS attestation documents if required by your compliance team.
If you are building a server-to-server integration that handles raw card data directly, a full PCI-DSS assessment is required. Consult your Aurora account team for guidance on the appropriate compliance path.
Production Credentials and Configuration
Environment Configuration
Keep the sandbox and production environments configurations strictly separated. Use environment-specific configuration files and never share credentials between environments.
# .env.production (never commit this file)
AURORA_CLIENT_ID=prod_client_id_here
AURORA_CLIENT_SECRET=prod_client_secret_here
AURORA_OAUTH_BASE_URL=https://oauth.arise.risewithaurora.com
AURORA_BASE_URL=https://api.arise.risewithaurora.com
# .env.sandbox (never commit this file)
AURORA_CLIENT_ID=sandbox_client_id_here
AURORA_CLIENT_SECRET=sandbox_client_secret_here
AURORA_OAUTH_BASE_URL=https://oauth.uat.arise.risewithaurora.com
AURORA_BASE_URL=https://api.uat.arise.risewithaurora.com
Aurora Elements in Production
Update the Aurora Elements script tag to load from the Production URL:
<!-- Sandbox -->
<script src="https://public.uat.arise.risewithaurora.com/lib/v1.0/arise.mjs" type="module"></script>
<!-- Production -->
<script src="https://public.arise.risewithaurora.com/lib/v1.0/arise.mjs" type="module"></script>
Go-Live Guide
The following sections detail the ISV and merchant integrators' certification procedures. It also allowing Aurora to track metrics of each. Follow the steps for the respective group.
ISV Certification
The following is for ISV (integrated software vendors).
Certification Requirements
ISVs must:
- Work directly with their assigned Aurora integration specialist.
- Provide a list of implemented API endpoints.
- Execute required test cases specific to their integration endpoints.
- Validate all required transaction flows, such as auth, sale, capture, refund, and void.
- Complete any required PCI validation if not using Aurora hosted solutions.
Test Case Execution
- Test cases are defined by Aurora based on the ISV’s integration scope.
- All validation must be completed in the sandbox environment.
- Results must be reviewed and approved by an Aurora integration specialist.
Merchant Certification
The following is for Merchant (Individual Merchant Integrators). There are two options for certification
- Self Certification
- Certification Requested.
Self Certification
Merchants who are confident in their work can directly go live with their production account credentials.
Certification Requested
Merchants can request that the Aurora Integrations team reviews the integrated development work.
Merchant certification focuses on confirming proper API usage, transaction processing, and portal visibility prior to go-live.
The Aurora Integrations team will provide next steps.
Contact:
Go-Live Approval
Go-Live Approval Before announcing launch to end users:
ISVs: A certification letter will be provided by the Aurora Integrations team to the ISV prior to production enablement.
Merchant Requested Certification. Merchants will be provided approval notification after Aurora confirms integration is properly implemented. Production credentials should not be used until certification approval has been granted.
Monitoring and Alerting Setup
Key Metrics to Monitor
Set up dashboards and alerts for the following before go-live:
| Metric | Alert Threshold | Severity |
|---|---|---|
| Payment success rate | < 95% over 5 minutes | Critical |
| Payment API P95 latency | > 3 seconds | Warning |
| Token refresh failure rate | Any failure | Critical |
| Rate limit (429) responses | > 5 in 1 minute | Warning |
| API 5xx error rate | > 1% over 5 minutes | Critical |
What to Log
Log enough information to reconstruct any failed transaction without storing sensitive card data:
// Good — enough context to investigate, no sensitive data
logger.info('Payment session created', {
sessionId: session.sessionId,
merchantId: config.merchantId,
amount: session.amount,
currency: session.currency,
correlationId: req.headers['x-correlation-id'],
});
logger.error('Payment declined', {
sessionId: session.sessionId,
errorCode: response.errorCode,
httpStatus: response.status,
correlationId: req.headers['x-correlation-id'],
});
// Bad — never log these
logger.info('Card submitted', {
cardNumber: '4111111111111111', // ❌ PCI violation
cvv: '123', // ❌ PCI violation
});
Support Channels
Contact Directory
| Scenario | Contact | Channel |
|---|---|---|
| Pre-launch integration questions | Aurora Integration Team | isvsupport@risewithaurora.com |
| Production outage or critical issue | Aurora Support | techsupport@risewithaurora.com — mark subject URGENT |
| Other questions or requests | Aurora Support | isvsupport@risewithaurora.com |
What to Include in a Support Request
Provide the following information when contacting Aurora support to minimize back-and-forth:
- Merchant ID — found in the Merchant Portal under Settings.
- Transaction ID or Session ID — the specific resource that failed.
- Timestamp — the exact time the issue occurred (include timezone).
- Request and response details — headers, status codes, and error codes (never include card data).
- Steps to reproduce — what actions trigger the issue.
- Impact — how many users or transactions are affected.