Testing - Ingo Payments Developer Hub

Sandbox Environment

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.

Test Categories

Category	Description	How to initiate
Self-Service	Complete independently in the sandbox at your own pace	Your sandbox credentials
Controlled	Requires an enablement flag set by your integration manager	Contact your integration manager to schedule
Guided	Live session with your Ingo integration team recommended	Contact your integration manager to schedule

Understanding Soft Failures

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.

Self-Service Scenarios

Notify API — Staging & Lifecycle

Successful Notification Delivery

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:

#	Event	Topic	Expected Status
1	Notification Sent	`transaction.recipient.notification.status.sent`	1200 series
2	Notification Received	`transaction.recipient.notification.status.received`	1200 series

Notification Bounce

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:

#	Event	Topic	Expected Status
1	Notification Sent	`transaction.recipient.notification.status.sent`	1200 series
2	Disbursement Canceled	`transaction.recipient.payment.disbursement.request.canceled`	1110

Cancel — Failure Conditions

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:

#	Event	Topic	Expected Status
—	Disbursement Expired	`transaction.recipient.payment.disbursement.request.expired`	1109

Notify Termination

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:

#	Event	Topic	Expected Status
1	Notification Sent	`transaction.recipient.notification.status.sent`	1200 series
2	Notification Received	`transaction.recipient.notification.status.received`	1200 series
3	Authentication Success	`transaction.recipient.authentication.status.success`	1100

Authentication — Soft Failure

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:

#	Event	Topic	Expected Status
1–2	Notification Sent / Received	(as above)	1200 series
3	Authentication Success	`transaction.recipient.authentication.status.success`	1101

Authentication — Hard Failure

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:

#	Event	Topic	Expected Status
1–2	Notification Sent / Received	(as above)	1200 series
3	Authentication Failure	`transaction.recipient.authentication.status.failure`	1102

Authentication — Max Attempts Termination

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:

#	Event	Topic	Expected Status
—	Authentication Failure	`transaction.recipient.authentication.status.failure`	1102
—	Overall Auth Failure	`transaction.party.authentication.overall.failure`	1161
—	Payment Terminated	`transaction.recipient.payment.status.terminated`	1113

RVDM — Success

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:

#	Event	Topic	Expected Status
—	CNS/CD Failure	`transaction.account.verification.card.failure.cns_cd`	700

Payment Scenarios — ACH

ACH — Successful Disbursement

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:

#	Event	Topic	Expected Status
1	Notification Sent	`transaction.recipient.notification.status.sent`	1200 series
2	Notification Received	`transaction.recipient.notification.status.received`	1200 series
3	Authentication Success	`transaction.recipient.authentication.status.success`	1100 or 1101
4	RVDM Success	`transaction.recipient.verification.rvdm.success`	1103 or 1104
5	PayPal AV Success	`transaction.account.verification.paypal.success.av`	1148
6	Tokenization Success	`transaction.account.tokenization.success`	100
7	Payment Success	`transaction.recipient.payment.status.success`	1134

PayPal — RVDM Soft Failure

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:

#	Event	Topic	Expected Status
1–3	Notification / Auth events	(as above)	—
4	RVDM Success	`transaction.recipient.verification.rvdm.success`	1104
5	PayPal AV Success	`transaction.account.verification.paypal.success.av`	1148
6	Tokenization Success	`transaction.account.tokenization.success`	100
7	Payment Success	`transaction.recipient.payment.status.success`	1134

PayPal — RVDM Hard Failure

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:

#	Event	Topic	Expected Status
1	Disbursement Expired	`transaction.recipient.payment.disbursement.request.expired`	1109
2	Payment Terminated	`transaction.recipient.payment.status.terminated`	1113

Check — Notification Expiration (Ingo Issuance)

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:

#	Event	Topic	Expected Status
—	Recipient Cancel	`transaction.recipient.payment.notice.status.recipient.cancel`	1139
—	Payment Terminated	`transaction.recipient.payment.status.terminated`	1113

Controlled Scenarios

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:

#	Event	Topic	Expected Status
1–2	Notification Sent / Received	(as above)	1200 series
3	Authentication Success	`transaction.recipient.authentication.status.success`	1100 or 1101
4	OTAC Generated	`transaction.party.authentication.otac.delivery.generate`	1153 or 1154
5	OTAC Validation Success	`transaction.party.authentication.otac.validation.success`	1150
6	Overall Auth Success	`transaction.party.authentication.overall.success`	1160

OTAC Validation — Failure

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:

#	Event	Topic	Expected Status
—	OTAC Generated	`transaction.party.authentication.otac.delivery.generate`	1153 or 1154
—	OTAC Validation Failure	`transaction.party.authentication.otac.validation.failure`	1152

OTAC — Max Failed Attempts Termination

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:

#	Event	Topic	Expected Status
—	OTAC Validation Failure	`transaction.party.authentication.otac.validation.failure`	1152
—	Overall Auth Failure	`transaction.party.authentication.overall.failure`	1161
—	Payment Terminated	`transaction.recipient.payment.status.terminated`	1113

OTAC — Send Limit Reached

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:

#	Event	Topic	Expected Status
—	OTAC Send Limit	`transaction.party.authentication.otac.delivery.limit`	1151
—	Overall Auth Failure	`transaction.party.authentication.overall.failure`	1162

OTAC — Inaccessible (Termination)

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:

#	Event	Topic	Expected Status
—	AVS/CVV Failure	`transaction.account.verification.card.failure.avs_cvv`	753–759 range

CVV Decline

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:

#	Event	Topic	Expected Status
—	AVS/CVV Failure	`transaction.account.verification.card.failure.avs_cvv`	—

ACH — GIACT Account Verification

ANV / NAV Soft Fail

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:

#	Event	Topic	Expected Status
1	Notification Sent	`transaction.recipient.notification.status.sent`	1200 series
2	Notification Received	`transaction.recipient.notification.status.received`	1200 series
3	Authentication Success	`transaction.recipient.authentication.status.success`	1100 or 1101
4	RVDM Success	`transaction.recipient.verification.rvdm.success`	1103 or 1104
5	Tokenization Success	`transaction.account.tokenization.success`	Soft-fail status code
6	Payment Success	`transaction.recipient.payment.status.success`	1126

RNV / ANV / NAV Hard Decline

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:

#	Event	Topic	Expected Status
1–4	Notification / Auth / RVDM events	(as above)	—
5	PayPal AV Success	`transaction.account.verification.paypal.success.av`	Soft-fail status code
6	Tokenization Success	`transaction.account.tokenization.success`	100
7	Payment Success	`transaction.recipient.payment.status.success`	1134

PayPal AV — Hard Fail & Max Attempts Termination

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:

#	Event	Topic	Expected Status
—	PayPal AV Failure	`transaction.account.verification.paypal.failure.av`	1150
Final	Payment Terminated	`transaction.recipient.payment.status.terminated`	1113

OFAC Screening

OFAC Suspended — Cleared (Payment Success)

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:

#	Event	Topic	Expected Status
1	OFAC Suspended	`transaction.recipient.verification.ofac.status.suspended`	1106
2	OFAC Cleared	`transaction.recipient.verification.ofac.status.cleared`	1107
3	Payment Success	`transaction.recipient.payment.status.success`	1125–1134

OFAC Suspended — Cleared (Payment Declined)

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:

#	Event	Topic	Expected Status
1	OFAC Suspended	`transaction.recipient.verification.ofac.status.suspended`	1106
2	OFAC Cleared	`transaction.recipient.verification.ofac.status.cleared`	1107
3	Payment Failure	`transaction.recipient.payment.status.failure`	—

OFAC Failure — Transaction Terminated

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:

#	Event	Topic	Expected Status
1	OFAC Suspended	`transaction.recipient.verification.ofac.status.suspended`	1106
2	OFAC Failure	`transaction.recipient.verification.ofac.status.failure`	1108
3	Payment Terminated	`transaction.recipient.payment.status.terminated`	1113

Guided Scenarios

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:

#	Event	Topic	Expected Status
—	Payment Returned	`transaction.recipient.payment.status.returned`	1114

Webhook Events Reference

Notification Events

Event	Topic	Expected Status
Notification Sent	`transaction.recipient.notification.status.sent`	1200 series
Notification Received	`transaction.recipient.notification.status.received`	1200 series
Notification Bounced	`transaction.recipient.notification.status.bounced`	1200 series

Authentication Events

Event	Topic	Expected Status
Auth Success	`transaction.recipient.authentication.status.success`	1100 (full), 1101 (soft fail)
Auth Failure	`transaction.recipient.authentication.status.failure`	1102
OTAC Generated	`transaction.party.authentication.otac.delivery.generate`	1153 (SMS), 1154 (email)
OTAC Send Limit	`transaction.party.authentication.otac.delivery.limit`	1151
OTAC Validation Success	`transaction.party.authentication.otac.validation.success`	1150
OTAC Validation Failure	`transaction.party.authentication.otac.validation.failure`	1152
Overall Auth Success	`transaction.party.authentication.overall.success`	1160
Overall Auth Failure	`transaction.party.authentication.overall.failure`	1161 (max attempts), 1162 (send limit), 1163 (inaccessible)

Verification Events

Event	Topic	Expected Status
RVDM Success	`transaction.recipient.verification.rvdm.success`	1103 (full), 1104 (soft fail)
RVDM Failure	`transaction.recipient.verification.rvdm.failure`	1105
OFAC Suspended	`transaction.recipient.verification.ofac.status.suspended`	1106
OFAC Cleared	`transaction.recipient.verification.ofac.status.cleared`	1107
OFAC Failure	`transaction.recipient.verification.ofac.status.failure`	1108

Account Verification Events

Event	Topic	Expected Status
Card CNS/CD Failure	`transaction.account.verification.card.failure.cns_cd`	700
Card AVS/CVV Failure	`transaction.account.verification.card.failure.avs_cvv`	753–759
ACH RNV Failure	`transaction.account.verification.ach.failure.rnv`	743
ACH ANV Failure	`transaction.account.verification.ach.failure.anv`	767–769
ACH NAV Failure	`transaction.account.verification.ach.failure.nav`	776–778
PayPal AV Failure	`transaction.account.verification.paypal.failure.av`	1150
PayPal AV Success	`transaction.account.verification.paypal.success.av`	1148
Tokenization Success	`transaction.account.tokenization.success`	100 (full), 111–119 (AVS soft fail)

Payment Status Events

Event	Topic	Expected Status
Payment Success — Card	`transaction.recipient.payment.status.success`	1125
Payment Success — ACH	`transaction.recipient.payment.status.success`	1126
Payment Success — Check	`transaction.recipient.payment.status.success`	1133
Payment Success — PayPal	`transaction.recipient.payment.status.success`	1134
Payment Failure	`transaction.recipient.payment.status.failure`	varies
Payment Terminated	`transaction.recipient.payment.status.terminated`	1113, 1132
Payment Returned	`transaction.recipient.payment.status.returned`	1114
Disbursement Expired	`transaction.recipient.payment.disbursement.request.expired`	1109
Disbursement Canceled	`transaction.recipient.payment.disbursement.request.canceled`	1110
Recipient Cancel	`transaction.recipient.payment.notice.status.recipient.cancel`	1139
Check In Process	`transaction.recipient.payment.status.check`	1111, 1112
Check Issued	`transaction.recipient.payment.status.check.issued`	100
Check Paid	`transaction.recipient.payment.status.check.paid`	100
Check Returned	`transaction.recipient.payment.status.check.returned`	1114

​Sandbox Environment

​Test Categories

​Understanding Soft Failures

​Self-Service Scenarios

Successful Notification Delivery

Notification Bounce

Idempotent Notify Request

Cancel — Successful

Cancel — Failure Conditions

Notification Expiration

Notify Termination

Authentication — Success

Authentication — Soft Failure

Authentication — Hard Failure

Authentication — Max Attempts Termination

RVDM — Success

RVDM — Soft Failure

RVDM — Hard Failure & Termination

Card — Successful Disbursement

Card — Repeat Recipient

Card — Account Not Available

ACH — Successful Disbursement

ACH — Repeat Recipient

ACH — RVDM Hard Failure

ACH — Session Termination

PayPal — Successful Disbursement

PayPal — RVDM Soft Failure

PayPal — RVDM Hard Failure

Check — Recipient-Elected (Client Issuance)

Check — Address Not Confirmed

Check — Notification Expiration (Client Issuance)

Check — Notification Expiration (Ingo Issuance)

Check — Ingo Issuance

Recipient-Initiated Cancellation

​Controlled Scenarios

OTAC Validation — Success

OTAC Validation — Failure

OTAC — Max Failed Attempts Termination

OTAC — Send Limit Reached

OTAC — Inaccessible (Termination)

AVS Soft Fail

AVS Decline

CVV Decline

ANV / NAV Soft Fail

RNV / ANV / NAV Hard Decline

PayPal AV — Soft Fail

PayPal AV — Hard Fail & Max Attempts Termination

OFAC Suspended — Cleared (Payment Success)

OFAC Suspended — Cleared (Payment Declined)

OFAC Failure — Transaction Terminated

​Guided Scenarios

Returned Payment

​Webhook Events Reference

Sandbox Environment

Test Categories

Understanding Soft Failures

Self-Service Scenarios

Controlled Scenarios

Guided Scenarios

Webhook Events Reference