Production Go-Live Guide
This guide walks you through every step required to move your Aurora integration from Sandbox to Production. Work through each section in order — skipping steps increases the risk of issues after launch.
Do not move to Production until you have completed end-to-end testing in Sandbox and received sign-off from your Aurora integration contact. Production transactions are real and 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 Sandbox | 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 Sandbox and Production 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 Sign-Off
Document the results of each smoke test and share them with your Aurora integration contact before announcing the launch to end users.
| Smoke Test | Expected Result | Status |
|---|---|---|
| Token generation | 200 OK, valid accessToken returned | [ ] Pass / [ ] Fail |
| Payment session creation (Aurora Elements) | 200 OK, sessionId returned | [ ] Pass / [ ] Fail |
| Payment session creation (POS Integration) | 200 OK, POS Transaction created | [ ] Pass / [ ] Fail |
| Successful $1.00 payment | Payment approved, appears in portal | [ ] Pass / [ ] Fail |
| Refund of $1.00 payment | Refund processed, status updated in portal | [ ] Pass / [ ] Fail |
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 | gatewaysupport@risewithaurora.com — mark subject URGENT |
| Other questions or requests | Aurora Support | gatewaysupport@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.