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

Ingo uses two distinct failure modes across verification and authentication services: 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 for a soft failure. 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.

A Note on Multi-Party Testing

Notify Managed Parties flows are scenario-driven, not scripted. Party roles, approval decisions, authentication outcomes, and disbursement selections are all made through live recipient and approver interactions. Because the orchestration responds dynamically to those interactions, testing is structured around intended outcomes rather than prescriptive step sequences. The verification mechanism for every scenario is the webhook event sequence — you know a scenario completed correctly when the expected events fire in the correct order.

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 delivered without bounceKey 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 Reminder

Category: Self-ServiceScenario: Stage a transaction. Receive the initial notification. Allow the reminder notification to fire without completing the disbursement.Success criteria: Both sent and reminder events receivedKey webhook sequence to verify:

#	Event	Topic	Expected Status
1	Notification Sent	`transaction.recipient.notification.status.sent`	1200 series
2	Notification Sent (Reminder)	`transaction.recipient.notification.status.sent`	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: Cancellation confirmed, disbursement request 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

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 fires, flow continues to account selectionKey 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. Open the notification and 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	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`	1101

Authentication — Hard Failure & Termination

Category: Self-ServiceScenario: Stage a transaction. Open the notification and provide non-matching authentication data until maximum attempts are reached. The recipient is stopped at each failure and may retry. After exhausting all attempts, the transaction terminates.Success criteria: Failure event fires, transaction terminatesKey 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 Failure	`transaction.recipient.authentication.status.failure`	1102
4	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: Stage a transaction with RVDM enabled. 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 to account selection 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: Stage a transaction with RVDM enabled. Provide non-matching recipient data until maximum attempts are exhausted. The recipient is stopped at each failure and may retry. After exhausting all attempts, the transaction terminates.Success criteria: RVDM failure event 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 the flow through authentication and RVDM. Select card disbursement and tokenize a valid test card. Payment processes successfully.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 transaction for a recipient with a previously tokenized card. Complete the flow using the existing token without re-entering card details.Success criteria: Payment completes using stored token, no re-tokenization required

Card — Account Not Available

Category: Self-ServiceScenario: Stage a transaction. 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 and enter a valid test routing and account number. Payment processes successfully.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

Payment Scenarios — PayPal

PayPal — Successful Disbursement

Category: Self-ServiceScenario: Stage a transaction. Complete authentication and select PayPal as the disbursement method. In the PayPal flow, PayPal Account Verification (AV) runs in place of RVDM. The AV success webhook notifies your system of the verification result in the background. The recipient experiences no interruption — the account is tokenized and payment processes successfully.Success criteria: PayPal AV success, tokenization success, and payment success all fire in sequenceKey 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	PayPal AV Success	`transaction.account.verification.paypal.success.av`	1148
5	Tokenization Success	`transaction.account.tokenization.success`	100
6	Payment Success	`transaction.recipient.payment.status.success`	1134

PayPal — Repeat Recipient

Category: Self-ServiceScenario: Stage a second PayPal transaction for a recipient with a previously registered PayPal account. Completes using the existing token.Success criteria: Payment completes using stored token

Payment Scenarios — Check

Check — Recipient-Elected (Client Issuance)

Category: Self-ServiceScenario: Stage a transaction. Complete the flow and have the recipient elect check as their disbursement method. 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. Open the notification, complete authentication, and have the recipient elect to cancel the disbursement from within the iFrame. Confirms your system handles recipient-initiated cancellation correctly.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.

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–3	Notification / Auth / RVDM events	(as above)	—
4	Tokenization Success	`transaction.account.tokenization.success`	111–119 range
5	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

AVS/CVV Max Attempts — Termination

Category: ControlledScenario: AVS or CVV hard failures repeat until the maximum attempt threshold is reached. The recipient is stopped at each failure and may retry. After exhausting all attempts, the transaction terminates.Success criteria: Termination event fires after max attemptsKey webhook sequence to verify:

#	Event	Topic	Expected Status
Final	Payment Terminated	`transaction.recipient.payment.status.terminated`	1113

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 — the flow continues transparently. Your system is notified of the partial match result 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 (RNV), account number (ANV), or name/address (NAV) 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

ACH — Max Attempts Termination

Category: ControlledScenario: ACH verification hard failures repeat until maximum attempts are exhausted. The recipient is stopped at each failure and may retry. After exhausting all attempts, the transaction terminates.Success criteria: Termination event fires after max attemptsKey webhook sequence to verify:

#	Event	Topic	Expected Status
Final	Payment Terminated	`transaction.recipient.payment.status.terminated`	1113

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–3	Notification / Auth events	(as above)	—
4	PayPal AV Success	`transaction.account.verification.paypal.success.av`	Soft-fail status code
5	Tokenization Success	`transaction.account.tokenization.success`	100
6	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. Your system is notified via the PayPal AV failure webhook.Success criteria: PayPal AV failure event 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 the transaction is cleared, but the payment is subsequently declined by the network.Success criteria: Suspended and cleared events fire; payment terminates after clearanceKey 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 multi-party orchestration and dynamic role interactions that benefit from coordination with your Ingo integration team. Contact your integration manager to schedule a guided session.

Multi-Party Approval Flows

Multi-party flows are scenario-driven by design. Party roles, approval decisions, and notification configurations interact dynamically based on your implementation setup. The key outcomes to validate during guided sessions:

Outcome	Key events to verify
Single approver — approved	`approvals.pmt-suspended` → `approvals.decision.approved` → `approvals.complete` → payment success
Single approver — declined	`approvals.pmt-suspended` → `approvals.decision.declined` → payment terminated
Multiple approvers — all approve	`approvals.pmt-suspended` → multiple `decision.approved` → `approvals.complete`
Multiple approvers — one declines	`approvals.pmt-suspended` → `decision.declined` → payment terminated
With notified parties	Party notification events firing alongside approval events

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 and updates your records.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
Party Notification Sent	`transaction.party.notification.status.sent`	1200 series
Party Notification Received	`transaction.party.notification.status.received`	1200 series
Party Notification Bounced	`transaction.party.notification.status.bounced`	1200 series

Authentication & Verification 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
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)

Approvals & Multi-Party Events

Event	Topic	Expected Status
Payment Suspended (Approvals)	`transaction.recipient.payment.status.approvals.pmt-suspended`	1170
Approval — Approved	`transaction.recipient.payment.status.approvals.decision.approved`	1123
Approval — Declined	`transaction.recipient.payment.status.approvals.decision.declined`	1124
Approvals Complete	`transaction.recipient.payment.status.approvals.complete`	1171

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 Canceled	`transaction.recipient.payment.status.check.canceled`	100
Check Stopped	`transaction.recipient.payment.status.check.stopped`	100
Check Returned	`transaction.recipient.payment.status.check.returned`	1114

​Sandbox Environment

​Test Categories

​Understanding Soft Failures

​A Note on Multi-Party Testing

​Self-Service Scenarios

Successful Notification Delivery

Notification Reminder

Notification Bounce

Idempotent Notify Request

Cancel — Successful

Cancel — Failure Conditions

Authentication — Success

Authentication — Soft Failure

Authentication — Hard Failure & 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

PayPal — Successful Disbursement

PayPal — Repeat Recipient

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

AVS Soft Fail

AVS Decline

AVS/CVV Max Attempts — Termination

ANV / NAV Soft Fail

RNV / ANV / NAV Hard Decline

ACH — Max Attempts Termination

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

A Note on Multi-Party Testing

Self-Service Scenarios

Controlled Scenarios

Guided Scenarios

Webhook Events Reference