Your sandbox mirrors production behavior including payment routing logic, OFAC screening, account verification services, and webhook delivery. Sandbox credentials and velocity limits are provisioned during onboarding.
Sandbox velocity limits are client-specific and configured by your Ingo integration manager during onboarding.
Soft failure — A partial match that does not stop the flow. The recipient experiences no interruption and proceeds transparently. Your system is notified of the result in the background via the correlated success webhook carrying the soft-fail status code. No failure webhook emits.Hard failure — A mismatch on a field your configuration has designated as requiring a hard failure. How each verification field’s mismatch is treated is defined during your implementation setup via the configuration form. When a hard failure occurs, the recipient is stopped and must retry. If maximum attempts are exhausted, the session or transaction terminates.
Category: Self-ServiceScenario: Stage a transaction via the Notify API. The recipient receives the notification email and it is delivered successfully.Success criteria: Notification sent and received events fireKey webhook sequence to verify:
Category: Self-ServiceScenario: Stage a transaction using an invalid email address. Confirms your system handles undeliverable notification events.Success criteria: Bounce event receivedKey webhook sequence to verify:
#
Event
Topic
Expected Status
1
Notification Sent
transaction.recipient.notification.status.sent
1200 series
2
Notification Bounced
transaction.recipient.notification.status.bounced
1200 series
Idempotent Notify Request
Category: Self-ServiceScenario: Resubmit an identical Notify API request using the same participant_unique_id1. Confirms duplicate protection is working correctly.Success criteria: Response status: 101 — no new transaction created
Cancel — Successful
Category: Self-ServiceScenario: Stage a transaction. Submit a Notify Cancel request before the recipient completes the flow. Confirms cancellation before disbursement selection.Success criteria: Disbursement canceled event firesKey webhook sequence to verify:
Category: Self-ServiceScenario: Attempt to cancel a transaction in a state that does not permit cancellation — already completed, already canceled, already expired, or invalid notification ID. Confirms your system handles cancel error responses gracefully.Success criteria: Appropriate error status returned for each invalid state
Notification Expiration
Category: Self-ServiceScenario: Stage a transaction. Allow the notification to expire without recipient action.Success criteria: Disbursement expired event firesKey webhook sequence to verify:
Category: Self-ServiceScenario: Stage a transaction. Complete the authentication flow in a way that causes the transaction to reach a terminal failure state.Success criteria: Payment terminated event firesKey webhook sequence to verify:
#
Event
Topic
Expected Status
—
Payment Terminated
transaction.recipient.payment.status.terminated
1113 or 1132
Recipient Authentication & RVDM
Authentication — Success
Category: Self-ServiceScenario: Stage a transaction. Open the notification and complete the authentication challenge with fully matching data. Recipient proceeds to disbursement selection.Success criteria: Authentication success event firesKey webhook sequence to verify:
Category: Self-ServiceScenario: Stage a transaction. Enter partially matching authentication data. The recipient experiences no interruption and proceeds transparently. Your system is notified of the partial match in the background via the authentication success webhook carrying the soft-fail status code.Success criteria: Authentication success fires with soft-fail status code; recipient proceeds uninterruptedKey webhook sequence to verify:
Category: Self-ServiceScenario: Stage a transaction. Provide non-matching authentication data. The recipient is stopped and must retry. Confirms hard failure handling.Success criteria: Authentication failure event firesKey webhook sequence to verify:
Category: Self-ServiceScenario: Provide non-matching authentication data until maximum attempts are exhausted. Transaction terminates.Success criteria: Authentication failure fires, overall failure fires, transaction terminatesKey webhook sequence to verify:
Category: Self-ServiceScenario: Stage a transaction with RVDM enabled. Complete authentication. Provide recipient information that fully matches the session data.Success criteria: RVDM success event fires, flow continues to account selectionKey webhook sequence to verify:
#
Event
Topic
Expected Status
1–3
Notification / Auth events
(as above)
—
4
RVDM Success
transaction.recipient.verification.rvdm.success
1103
RVDM — Soft Failure
Category: Self-ServiceScenario: Provide partially matching recipient data. The recipient experiences no interruption and proceeds transparently. Your system is notified of the partial match in the background via the RVDM success webhook carrying the soft-fail status code.Success criteria: RVDM success fires with soft-fail status code; recipient proceeds uninterruptedKey webhook sequence to verify:
#
Event
Topic
Expected Status
1–3
Notification / Auth events
(as above)
—
4
RVDM Success
transaction.recipient.verification.rvdm.success
1104
RVDM — Hard Failure & Termination
Category: Self-ServiceScenario: Provide non-matching recipient data until maximum attempts are exhausted. Transaction terminates.Success criteria: RVDM failure fires, transaction terminatesKey webhook sequence to verify:
#
Event
Topic
Expected Status
1–3
Notification / Auth events
(as above)
—
4
RVDM Failure
transaction.recipient.verification.rvdm.failure
1105
5
Payment Terminated
transaction.recipient.payment.status.terminated
1113
Payment Scenarios — Card
Card — Successful Disbursement
Category: Self-ServiceScenario: Stage a transaction. Complete authentication and RVDM. Select card disbursement, tokenize a valid test card, and complete the payment.Success criteria: Tokenization and payment success events fireKey webhook sequence to verify:
#
Event
Topic
Expected Status
1–4
Notification / Auth / RVDM events
(as above)
—
5
Tokenization Success
transaction.account.tokenization.success
100
6
Payment Success
transaction.recipient.payment.status.success
1125
Card — Repeat Recipient
Category: Self-ServiceScenario: Stage a second card transaction for a recipient with a previously tokenized account. Completes using the existing token without re-entering card details.Success criteria: Payment completes using stored token
Card — Account Not Available
Category: Self-ServiceScenario: Enter a card account number not supported for disbursement. The recipient is stopped and must use a different account. Your system is notified via the CNS/CD failure webhook.Success criteria: CNS/CD failure event firesKey webhook sequence to verify:
Category: Self-ServiceScenario: Stage a transaction. Complete authentication and RVDM. Select ACH disbursement, enter a valid test routing and account number, and complete the payment.Success criteria: Tokenization and payment success events fireKey webhook sequence to verify:
#
Event
Topic
Expected Status
1–4
Notification / Auth / RVDM events
(as above)
—
5
Tokenization Success
transaction.account.tokenization.success
100
6
Payment Success
transaction.recipient.payment.status.success
1126
ACH — Repeat Recipient
Category: Self-ServiceScenario: Stage a second ACH transaction for a recipient with a previously registered account. Completes using the existing token.Success criteria: Payment completes using stored token
ACH — RVDM Hard Failure
Category: Self-ServiceScenario: Stage an ACH transaction. Provide non-matching session recipient information during account entry. Confirms hard failure stops the flow before tokenization.Success criteria: RVDM failure fires; no tokenizationKey webhook sequence to verify:
#
Event
Topic
Expected Status
—
RVDM Failure
transaction.recipient.verification.rvdm.failure
1105
ACH — Session Termination
Category: Self-ServiceScenario: Provide non-matching session recipient information repeatedly until the session terminates.Success criteria: Session terminated event firesKey webhook sequence to verify:
#
Event
Topic
Expected Status
—
Session Terminated
plugin.transaction.session.request.terminated
1127
Payment Scenarios — PayPal
PayPal — Successful Disbursement
Category: Self-ServiceScenario: Stage a transaction. Complete authentication and RVDM. Select PayPal disbursement. PayPal Account Verification (AV) runs as the PayPal-specific account check. The AV result notifies your system in the background. The account is tokenized and payment completes.Success criteria: RVDM success, PayPal AV success, tokenization success, and payment success all fireKey webhook sequence to verify:
Category: Self-ServiceScenario: Stage a PayPal transaction. Provide partially matching session recipient data. The recipient experiences no interruption. Your system is notified of the partial RVDM match in the background via the RVDM success webhook. The flow continues to PayPal AV and tokenization.Success criteria: RVDM success fires with soft-fail code; PayPal flow continues; payment completesKey webhook sequence to verify:
Category: Self-ServiceScenario: Stage a PayPal transaction. Provide non-matching session recipient data. The RVDM hard failure stops the flow before PayPal AV or tokenization.Success criteria: RVDM failure fires; no PayPal AV or tokenizationKey webhook sequence to verify:
#
Event
Topic
Expected Status
—
RVDM Failure
transaction.recipient.verification.rvdm.failure
1105
Payment Scenarios — Check
Check — Recipient-Elected (Client Issuance)
Category: Self-ServiceScenario: Stage a transaction. Complete the full flow. Recipient elects check. Client issues the check.Success criteria: Check in process event fires confirming the recipient elected checkKey webhook sequence to verify:
#
Event
Topic
Expected Status
—
Check In Process
transaction.recipient.payment.status.check
1111 or 1112
Check — Address Not Confirmed
Category: Self-ServiceScenario: Stage a check transaction. Recipient selects check but does not confirm the address on file.Success criteria: Check in process event fires with address-not-confirmed status codeKey webhook sequence to verify:
#
Event
Topic
Expected Status
—
Check In Process
transaction.recipient.payment.status.check
1112
Check — Notification Expiration (Client Issuance)
Category: Self-ServiceScenario: Stage a Client Issuance check transaction. Allow the notification to expire without recipient action. The disbursement request expires and the transaction terminates.Success criteria: Expired event fires; transaction terminatesKey webhook sequence to verify:
Category: Self-ServiceScenario: Stage an Ingo Issuance check transaction. Allow the notification to expire without recipient action. Ingo defaults to issuing the check — the payment succeeds and the check is issued and subsequently paid.Success criteria: Payment success fires, followed by check issued and check paid eventsKey webhook sequence to verify:
#
Event
Topic
Expected Status
1
Payment Success
transaction.recipient.payment.status.success
1133
2
Check Issued
transaction.recipient.payment.status.check.issued
100
3
Check Paid
transaction.recipient.payment.status.check.paid
100
Check — Ingo Issuance
Category: Self-ServiceScenario: Stage a transaction configured for Ingo check issuance. Complete the full flow. Ingo issues the check and it is subsequently paid.Success criteria: Payment success, check issued, and check paid events all fireKey webhook sequence to verify:
#
Event
Topic
Expected Status
1
Payment Success
transaction.recipient.payment.status.success
1133
2
Check Issued
transaction.recipient.payment.status.check.issued
100
3
Check Paid
transaction.recipient.payment.status.check.paid
100
Recipient Cancel
Recipient-Initiated Cancellation
Category: Self-ServiceScenario: Stage a transaction. Complete authentication and have the recipient elect to cancel the disbursement from within the iFrame.Success criteria: Recipient cancel event fires, transaction terminatesKey webhook sequence to verify:
The following scenarios require your Ingo integration manager to enable a specific configuration before testing can begin. Contact your integration team to schedule these.
OTAC — One-Time Authentication Code
OTAC is a configurable authentication method where a one-time code is delivered to the recipient’s mobile number during the authentication flow. The following scenarios require OTAC to be enabled in your sandbox configuration.
OTAC Validation — Success
Category: ControlledScenario: Stage a transaction with OTAC enabled. Complete the RA challenge. Receive the OTAC code on the registered mobile number and enter it correctly. Authentication completes successfully.Success criteria: OTAC generate, validation success, and overall auth success events all fireKey webhook sequence to verify:
Category: ControlledScenario: Enter an incorrect OTAC code. The recipient is stopped and may retry. Confirms validation failure handling.Success criteria: OTAC validation failure event fires; retry permittedKey webhook sequence to verify:
Category: ControlledScenario: Enter incorrect OTAC codes until maximum attempts are exhausted. Transaction terminates.Success criteria: OTAC validation failure fires repeatedly; overall auth failure fires; transaction terminatesKey webhook sequence to verify:
Category: ControlledScenario: Request OTAC code delivery repeatedly until the send limit is reached. Confirms your system handles the send limit event.Success criteria: OTAC delivery limit event fires; overall auth failure firesKey webhook sequence to verify:
Category: ControlledScenario: OTAC cannot be delivered or accessed (e.g., no mobile number available). Transaction terminates.Success criteria: Overall auth failure fires with inaccessible status; transaction terminatesKey webhook sequence to verify:
#
Event
Topic
Expected Status
—
Overall Auth Failure
transaction.party.authentication.overall.failure
1163
—
Payment Terminated
transaction.recipient.payment.status.terminated
1113
Card — AVS & CVV Risk Management
AVS Soft Fail
Category: ControlledScenario: A card account tokenization where the AVS check returns a soft failure. The recipient experiences no interruption and proceeds transparently. Your system is notified of the partial address match in the background via the tokenization success webhook carrying the soft-fail status code.Success criteria: Tokenization success fires with AVS soft-fail status code; payment completesKey webhook sequence to verify:
#
Event
Topic
Expected Status
1–4
Notification / Auth / RVDM events
(as above)
—
5
Tokenization Success
transaction.account.tokenization.success
111–119 range
6
Payment Success
transaction.recipient.payment.status.success
1125
AVS Decline
Category: ControlledScenario: A card account tokenization where the AVS check returns a hard decline. The recipient is stopped and must use a different account. Your system is notified via the AVS/CVV failure webhook.Success criteria: AVS/CVV failure event fires; account rejectedKey webhook sequence to verify:
Category: ControlledScenario: A card account tokenization where the CVV check returns a hard decline. Your system is notified via the AVS/CVV failure webhook.Success criteria: AVS/CVV failure event fires; account rejectedKey webhook sequence to verify:
Category: ControlledScenario: An ACH account verification returns a soft failure on account number validation (ANV) or name/address validation (NAV). The recipient experiences no interruption. Your system is notified of the partial match in the background via the tokenization success webhook carrying the soft-fail status code.Success criteria: Tokenization success fires with soft-fail status code; payment completesKey webhook sequence to verify:
Category: ControlledScenario: ACH account verification returns a hard decline on routing number, account number, or name/address validation. The recipient is stopped and must use a different account. Your system is notified via the appropriate failure webhook.Success criteria: Applicable failure event fires; account rejectedKey webhook sequence to verify:
#
Event
Topic
Expected Status
—
RNV Failure
transaction.account.verification.ach.failure.rnv
743
—
or ANV Failure
transaction.account.verification.ach.failure.anv
767–769
—
or NAV Failure
transaction.account.verification.ach.failure.nav
776–778
PayPal — Account Verification
PayPal AV — Soft Fail
Category: ControlledScenario: PayPal account verification returns a partial match. The recipient experiences no interruption and proceeds transparently. Your system is notified of the partial match in the background via the PayPal AV success webhook carrying the soft-fail status code. The account is tokenized and payment completes.Success criteria: PayPal AV success fires with soft-fail status code; tokenization and payment success followKey webhook sequence to verify:
Category: ControlledScenario: PayPal account verification returns a hard failure. The recipient is stopped and must retry. If maximum attempts are reached, the transaction terminates.Success criteria: PayPal AV failure fires; termination event fires after max attemptsKey webhook sequence to verify:
Category: ControlledScenario: A staged transaction triggers an OFAC hit during the disbursement flow. The payment is suspended. After OFAC review, the transaction is cleared and payment completes.Success criteria: Suspended and cleared events both fire; payment ultimately succeedsKey webhook sequence to verify:
Category: ControlledScenario: An OFAC suspension is reviewed and cleared, but payment is subsequently declined by the network.Success criteria: Suspended and cleared events fire; payment failure firesKey webhook sequence to verify:
Category: ControlledScenario: An OFAC suspension is reviewed and confirmed. The transaction is terminated.Success criteria: Suspended and failure events fire; transaction terminatesKey webhook sequence to verify:
The following scenarios involve coordination with your Ingo integration team. Contact your integration manager to schedule a guided session.
Returned & Refunded Payments
Returned Payment
Category: GuidedScenario: A previously completed payment is returned by the account issuer. Confirms your system correctly handles the returned status.Success criteria: Returned event received and processed correctlyKey webhook sequence to verify:
