Sandbox and launch
Arrange sandbox access, connect the payment journey and prepare the account for launch. Our integration team provides the setup requirements and confirms the steps needed before live processing.
Developers and operations teamsBefore you begin
- The connection settings and services you plan to use
- Sandbox accounts, credentials and data supplied by our integration team
- Contacts for integration setup, launch and ongoing support
On this page
Configure sandbox access
Keep the account references, documentation version, website origins, payment settings and event subscriptions together. Sandbox credentials, receivers and records must stay separate from production. Use the sandbox data supplied by our integration team.
- 01 · ConfigurationConfirm the setupAccounts, versions and methods
- 02 · PaymentsConfirm payment resultsCompleted, declined and interrupted payments
- 03 · ReviewComplete the reviewConfiguration and outstanding questions
- 04 · ProductionConfirm the live setupProduction access and support contacts
Confirm payment behavior
For each enabled payment method, follow the customer journey and compare the displayed result with the account or payment record. Retain the relevant references so your team can trace any difference.
- Setup
- The check, account, environment and configuration used.
- Result
- The expected result, what happened and the relevant records with sensitive details removed.
- Review
- Whether the result matches the expected behavior, who reviewed it and any issue still needing resolution.
| Scenario | Result to confirm |
|---|---|
| Merchant setup | An incomplete or partially configured account cannot use the affected processing function. Keep the application reference, review result and required service results. |
| Account permissions | Changing an account ID supplied by the browser cannot retrieve or change another merchant’s records. Keep the rejected request reference and permission decision. |
| Approved payment | One intended payment operation matches the order, amount, currency and merchant. Keep the attempt, transaction and verified operation status. |
| Decline or authentication cancellation | The order is not fulfilled and the customer has a usable next step. Keep the processing result and outcome shown to the customer. |
| Lost response or concurrent submission | The original attempt is resolved before a retry. Refreshes and concurrent tabs do not duplicate a charge or fulfillment. Keep the request and recovery references. |
| Invalid, repeated or delayed event | Invalid data cannot change state. Repeated delivery has one business effect, and an older event cannot regress a confirmed result. Keep receipt and processing evidence. |
| Refund or dispute operation | Use only the permissions granted to the account. A refund beyond the remaining refundable amount is refused, and a permitted action retains its own reference and outcome. |
| Funding and reconciliation | Trace activity and adjustments into the reported deposit. Distinguish submitted instructions, rejected items and confirmed funding states. Keep reconciliation references. |
| Configured methods and devices | Check enabled wallets on eligible devices, authentication paths and outcomes specific to ACH where available. Confirm each enabled method rather than inferring it from a successful card entry. |
Run the journey as a customer
Follow an order from sandbox checkout to its payment and account records. Confirm that the customer and your operations team can understand the result and find the next action.
Confirm account readiness
Use the correct business and configured merchant mapping. Check that incomplete setup is distinguished from an approved and usable processing connection.
Complete checkout and interruption paths
Check desktop and mobile checkout, including a completed payment, a decline and an interrupted response. Keep an uncertain attempt open for investigation before asking the customer to pay again.
Find the same transaction in operations
Trace the order to the processing record. Check permitted refunds and dispute actions with their own references, permissions and recorded outcomes.
Reconcile the funding record
Explain the reported amount from payments and adjustments. A sandbox funding record does not confirm bank receipt; live bank receipt needs a separate, authorized check.
When the interface and records disagree
Record the customer message, payment state and relevant references. Resolve the discrepancy before confirming that the checkout setup is ready.
The customer, support team and finance team can follow the same transaction without confusing submission, authorization, capture or bank receipt.
Complete the integration review
Work with our integration team to confirm account setup, checkout, payment events and reporting, including recovery from interrupted payments.
Record any required certification and the configuration it covers. Fix problems and repeat the affected checks. Keep a payment method or connection disabled until its own checks are complete.
| Decision | What to confirm |
|---|---|
| Ready for live checks | Checkout, payment recovery and account permissions work as documented. Outstanding issues are resolved and the required integration review or certification is recorded. |
| Not ready | Account permissions, payment verification, recovery or a required operation still needs confirmation. Keep that function disabled until it is ready. |
| The integration has changed | Adding a payment method or changing a connection or processing setting requires the relevant checks and any required certification again. |
Validate the production setup and launch
Compare the production configuration
Confirm production account references, credentials, website origins, payment methods, capture settings and event subscriptions with our integration team. Keep sandbox credentials separate from production.
Agree the live payment checks
Agree who will perform the checks, which actions are permitted, the limits and when to stop with the account team. Any live application, transaction, refund or movement of funds requires that separate procedure.
Confirm reporting and receipt
Trace the authorized activity into merchant records, events and funding reports. Where the validation includes a bank deposit, confirm actual bank receipt separately from a submitted or funded service status.
Confirm who will support the service
Assign monitoring and support for payment uncertainty, refunds, disputes, credential incidents and reconciliation. Record who can pause new activity if an unexplained result appears.
If a live check fails
Pause new activity for the affected connection or method. Preserve pending attempts and continue the authorized recovery and reconciliation process. A software rollback does not reverse a financial operation already accepted.
What to monitor first
Watch unresolved attempts, verification failures, receiver and worker failures, delayed reports and unexplained reconciliation differences. Follow the agreed alert thresholds and contact the person responsible for each issue.
Launch only the services confirmed by the live checks, with the support team ready to handle ongoing payment activity.
Support the service after launch
Keep the integration documentation, configuration, launch approval and support contacts together. Review the affected payment flow with our integration team before changing a connection or adding a payment method.
- For a support request
- Include the environment, affected merchant, record and attempt references, timestamp with time zone, expected outcome and observed result. Share redacted diagnostics through the approved channel.
- For an incident
- Identify whether the problem is access, payment processing, delivery, worker execution or reconciliation. Assign someone to investigate and resolve uncertain attempts before retrying.