Before promoting an integration to production, a final verification must confirm that all technical, operational, and functional requirements have been satisfied.

This checklist represents the final control point to ensure that the integration is not only correct in isolation but also ready to operate reliably under real production conditions, including asynchronous processing, failure scenarios, and operational monitoring.

Configuration and Environment Readiness

• All endpoints are configured for the correct production environment
• No Sandbox credentials or configurations are present in production
• AuthToken, X-IBM-Client-Id, and terminalId are valid and correctly provisioned
• Webhook endpoints are reachable and correctly configured
• Network communication is secured (HTTPS) and stable

See F.6.1 – Environment and Configuration Readiness.

End-to-End Flow Validation

• All supported payment methods and flows have been validated end-to-end
• All transaction lifecycle stages are correctly handled (initial, intermediate, final)
• Asynchronous behavior is correctly implemented and validated
• Webhook notifications are received and processed correctly
• Final transaction state is confirmed via validated final paymentStatus data or via Status Inquiry when required
• Inquiry Details metadata is available for extended transaction investigation and reconciliation analysis where required

See F.6.5 – End-to-End Flow Validation Before Go-Live.

Transaction Outcome Handling

• All outcome scenarios are correctly handled:
  • Success
  • Declined
  • Pending
  • Timeout / unknown outcomes
• paymentStatus and returnStatus are correctly interpreted
• Business logic is aligned with final transaction state

See F.3 – Success and Error Scenarios.

Idempotency and Duplicate Protection

• Duplicate requests do not create duplicate transactions
• Duplicate webhook notifications are safely handled
• Webhook replay scenarios do not trigger duplicate downstream business processing
• Retry mechanisms are controlled and state-aware
• Transaction identifiers (merchant.merchantTransactionId, transactionID) are consistently used

See F.6.2 – Transaction Idempotency and Duplicate Protection.

Asynchronous Flow Readiness

• Pending states are fully supported and correctly handled
• Business actions are deferred until final state confirmation
• System tolerates delayed, duplicated, and out-of-order events
• Event-driven processing is aligned with validated transaction state
• Temporary discrepancies between webhook notifications, Status Inquiry responses, Inquiry Details responses, and internal Merchant system state are correctly reconciled

See F.6.3 – Asynchronous Flow Readiness.

Webhook Reliability and Processing

• Webhooks are processed idempotently
• Event handling is order-independent
• Fast acknowledgment of webhook reception is implemented
• Webhook authenticity and configured security-verification mechanisms are validated correctly
• Fallback mechanisms (Status Inquiry) are in place

See F.6.4 – Webhook Reliability and Processing Guarantees.

Operational Resilience and Failure Handling

• Failure scenarios are correctly classified and handled
• Unknown states are resolved via the Status Inquiry
• Retry strategies are controlled and safe
• All transactions are eventually resolved to a final or operationally handled state
• Recovery and reconciliation mechanisms continue until transaction-state consistency is achieved

Retry strategies are correctly applied only to temporary conditions (statusCode = Txxxx) and not to validation or business errors (statusCode = Exxxx).

See F.6.6 – Operational Resilience and Failure Strategy.

Observability and Monitoring

• All transactions are traceable end-to-end
• Correlation identifiers (transactionID, merchant.merchantTransactionId and notificationID when logging webhook processing) are logged
• Monitoring and alerting are in place for key operational signals
• Failures, anomalies, and inconsistencies can be detected and diagnosed
• Webhook-processing backlogs, unresolved retries, and prolonged asynchronous recovery conditions are operationally visible

See F.6.7 – Production Observability Prerequisites for observability, monitoring, traceability, and operational diagnostics requirements.

Data Integrity and Consistency

• Transaction data is validated at all stages
• Data remains consistent across all systems
• Validated transaction state is consistently respected
• Reconciliation processes are implemented and verified

See F.6.8 – Data Integrity and Consistency Controls.

Operational Readiness

• System behaves correctly under realistic production conditions:
  • Network latency
  • Concurrent transactions
  • Transient failures
• No dependency on synchronous assumptions
• System can sustain the full transaction lifecycle reliably under production conditions

Final Go-Live Criteria

An integration is ready for production only when:

• All checklist items have been validated
• No critical gaps remain in configuration, behavior, or observability
• All flows behave correctly under asynchronous and non-deterministic conditions
• Transaction integrity and consistency are guaranteed

Failure to satisfy these criteria introduces operational risk and potential financial impact.

Final Consideration

The go-live checklist is the final gate before production deployment.

A production-ready integration ensures that:

• All technical and operational requirements are fulfilled
• System behavior is predictable and reliable under real-world conditions
• All risks related to asynchronous processing, failure, and data consistency are controlled

Proceeding to production without completing this validation exposes the system to avoidable failures, inconsistencies, and financial risk.

Error handling behavior is aligned with the classification model defined in C.5 – Status Codes and Error Codes Mapping and C.6 – Error Payloads and Handling Guidelines.