> ## Documentation Index
> Fetch the complete documentation index at: https://developers.ingopayments.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing

> Scenario-based testing guide for Notify Managed Parties staged disbursements, multi-party approval flows, and webhook event verification.

## 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.

<Info>
  Sandbox velocity limits are client-specific and configured by your Ingo integration manager during onboarding.
</Info>

***

## 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

<AccordionGroup>
  <Accordion title="Notify API — Staging & Lifecycle">
    <Card title="Successful Notification Delivery" icon="envelope">
      **Category:** Self-Service

      **Scenario:** Stage a transaction via the Notify API. The recipient receives the notification email and it is delivered successfully.

      **Success criteria:** Notification delivered without bounce

      **Key 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     |
    </Card>

    <Card title="Notification Reminder" icon="bell">
      **Category:** Self-Service

      **Scenario:** Stage a transaction. Receive the initial notification. Allow the reminder notification to fire without completing the disbursement.

      **Success criteria:** Both sent and reminder events received

      **Key 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     |
    </Card>

    <Card title="Notification Bounce" icon="envelope-circle-check">
      **Category:** Self-Service

      **Scenario:** Stage a transaction using an invalid email address. Confirms your system handles undeliverable notification events.

      **Success criteria:** Bounce event received

      **Key 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     |
    </Card>

    <Card title="Idempotent Notify Request" icon="rotate">
      **Category:** Self-Service

      **Scenario:** 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
    </Card>

    <Card title="Cancel — Successful" icon="ban">
      **Category:** Self-Service

      **Scenario:** 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 fires

      **Key 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            |
    </Card>

    <Card title="Cancel — Failure Conditions" icon="circle-xmark">
      **Category:** Self-Service

      **Scenario:** 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
    </Card>
  </Accordion>

  <Accordion title="Recipient Authentication & RVDM">
    <Card title="Authentication — Success" icon="shield-check">
      **Category:** Self-Service

      **Scenario:** 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 selection

      **Key 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            |
    </Card>

    <Card title="Authentication — Soft Failure" icon="shield">
      **Category:** Self-Service

      **Scenario:** 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 uninterrupted

      **Key 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            |
    </Card>

    <Card title="Authentication — Hard Failure & Termination" icon="shield-xmark">
      **Category:** Self-Service

      **Scenario:** 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 terminates

      **Key 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            |
    </Card>

    <Card title="RVDM — Success" icon="user-check">
      **Category:** Self-Service

      **Scenario:** 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 selection

      **Key webhook sequence to verify:**

      | #   | Event                      | Topic                                             | Expected Status |
      | --- | -------------------------- | ------------------------------------------------- | --------------- |
      | 1–3 | Notification / Auth events | *(as above)*                                      | —               |
      | 4   | RVDM Success               | `transaction.recipient.verification.rvdm.success` | 1103            |
    </Card>

    <Card title="RVDM — Soft Failure" icon="user">
      **Category:** Self-Service

      **Scenario:** 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 uninterrupted

      **Key webhook sequence to verify:**

      | #   | Event                      | Topic                                             | Expected Status |
      | --- | -------------------------- | ------------------------------------------------- | --------------- |
      | 1–3 | Notification / Auth events | *(as above)*                                      | —               |
      | 4   | RVDM Success               | `transaction.recipient.verification.rvdm.success` | 1104            |
    </Card>

    <Card title="RVDM — Hard Failure & Termination" icon="user-xmark">
      **Category:** Self-Service

      **Scenario:** 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 terminates

      **Key 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            |
    </Card>
  </Accordion>

  <Accordion title="Payment Scenarios — Card">
    <Card title="Card — Successful Disbursement" icon="credit-card">
      **Category:** Self-Service

      **Scenario:** 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 fire

      **Key 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>

    <Card title="Card — Repeat Recipient" icon="rotate-right">
      **Category:** Self-Service

      **Scenario:** 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>

    <Card title="Card — Account Not Available" icon="credit-card-front">
      **Category:** Self-Service

      **Scenario:** 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 fires

      **Key webhook sequence to verify:**

      | # | Event          | Topic                                                  | Expected Status |
      | - | -------------- | ------------------------------------------------------ | --------------- |
      | — | CNS/CD Failure | `transaction.account.verification.card.failure.cns_cd` | 700             |
    </Card>
  </Accordion>

  <Accordion title="Payment Scenarios — ACH">
    <Card title="ACH — Successful Disbursement" icon="building-columns">
      **Category:** Self-Service

      **Scenario:** 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 fire

      **Key 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            |
    </Card>

    <Card title="ACH — Repeat Recipient" icon="rotate-right">
      **Category:** Self-Service

      **Scenario:** 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
    </Card>
  </Accordion>

  <Accordion title="Payment Scenarios — PayPal">
    <Card title="PayPal — Successful Disbursement" icon="paypal">
      **Category:** Self-Service

      **Scenario:** 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 sequence

      **Key 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            |
    </Card>

    <Card title="PayPal — Repeat Recipient" icon="rotate-right">
      **Category:** Self-Service

      **Scenario:** 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
    </Card>
  </Accordion>

  <Accordion title="Payment Scenarios — Check">
    <Card title="Check — Recipient-Elected (Client Issuance)" icon="money-check">
      **Category:** Self-Service

      **Scenario:** 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 check

      **Key webhook sequence to verify:**

      | # | Event            | Topic                                        | Expected Status |
      | - | ---------------- | -------------------------------------------- | --------------- |
      | — | Check In Process | `transaction.recipient.payment.status.check` | 1111 or 1112    |
    </Card>

    <Card title="Check — Address Not Confirmed" icon="location-dot">
      **Category:** Self-Service

      **Scenario:** 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 code

      **Key webhook sequence to verify:**

      | # | Event            | Topic                                        | Expected Status |
      | - | ---------------- | -------------------------------------------- | --------------- |
      | — | Check In Process | `transaction.recipient.payment.status.check` | 1112            |
    </Card>

    <Card title="Check — Notification Expiration (Client Issuance)" icon="clock">
      **Category:** Self-Service

      **Scenario:** 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 terminates

      **Key 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            |
    </Card>

    <Card title="Check — Notification Expiration (Ingo Issuance)" icon="clock">
      **Category:** Self-Service

      **Scenario:** 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 events

      **Key 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             |
    </Card>

    <Card title="Check — Ingo Issuance" icon="envelope-open-dollar">
      **Category:** Self-Service

      **Scenario:** 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 fire

      **Key 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             |
    </Card>
  </Accordion>

  <Accordion title="Recipient Cancel">
    <Card title="Recipient-Initiated Cancellation" icon="hand">
      **Category:** Self-Service

      **Scenario:** 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 terminates

      **Key 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            |
    </Card>
  </Accordion>
</AccordionGroup>

***

## Controlled Scenarios

<Warning>
  The following scenarios require your Ingo integration manager to enable a specific configuration before testing can begin. Contact your integration team to schedule these.
</Warning>

<AccordionGroup>
  <Accordion title="Card — AVS & CVV Risk Management">
    <Card title="AVS Soft Fail" icon="location-crosshairs">
      **Category:** Controlled

      **Scenario:** 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 completes

      **Key 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            |
    </Card>

    <Card title="AVS Decline" icon="location-dot-slash">
      **Category:** Controlled

      **Scenario:** 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 rejected

      **Key webhook sequence to verify:**

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

    <Card title="AVS/CVV Max Attempts — Termination" icon="shield-slash">
      **Category:** Controlled

      **Scenario:** 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 attempts

      **Key webhook sequence to verify:**

      | #     | Event              | Topic                                             | Expected Status |
      | ----- | ------------------ | ------------------------------------------------- | --------------- |
      | Final | Payment Terminated | `transaction.recipient.payment.status.terminated` | 1113            |
    </Card>
  </Accordion>

  <Accordion title="ACH — GIACT Account Verification">
    <Card title="ANV / NAV Soft Fail" icon="building-columns">
      **Category:** Controlled

      **Scenario:** 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 completes

      **Key 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                  |
    </Card>

    <Card title="RNV / ANV / NAV Hard Decline" icon="ban">
      **Category:** Controlled

      **Scenario:** 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 rejected

      **Key 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         |
    </Card>

    <Card title="ACH — Max Attempts Termination" icon="circle-exclamation">
      **Category:** Controlled

      **Scenario:** 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 attempts

      **Key webhook sequence to verify:**

      | #     | Event              | Topic                                             | Expected Status |
      | ----- | ------------------ | ------------------------------------------------- | --------------- |
      | Final | Payment Terminated | `transaction.recipient.payment.status.terminated` | 1113            |
    </Card>
  </Accordion>

  <Accordion title="PayPal — Account Verification">
    <Card title="PayPal AV — Soft Fail" icon="paypal">
      **Category:** Controlled

      **Scenario:** 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 follow

      **Key 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                  |
    </Card>

    <Card title="PayPal AV — Hard Fail & Max Attempts Termination" icon="circle-xmark">
      **Category:** Controlled

      **Scenario:** 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 attempts

      **Key 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            |
    </Card>
  </Accordion>

  <Accordion title="OFAC Screening">
    <Card title="OFAC Suspended — Cleared (Payment Success)" icon="flag">
      **Category:** Controlled

      **Scenario:** 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 succeeds

      **Key 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       |
    </Card>

    <Card title="OFAC Suspended — Cleared (Payment Declined)" icon="flag-checkered">
      **Category:** Controlled

      **Scenario:** 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 clearance

      **Key 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`             | —               |
    </Card>

    <Card title="OFAC Failure — Transaction Terminated" icon="triangle-exclamation">
      **Category:** Controlled

      **Scenario:** An OFAC suspension is reviewed and confirmed. The transaction is terminated.

      **Success criteria:** Suspended and failure events fire; transaction terminates

      **Key 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            |
    </Card>
  </Accordion>
</AccordionGroup>

***

## Guided Scenarios

<Warning>
  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.
</Warning>

<AccordionGroup>
  <Accordion title="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                                         |
  </Accordion>

  <Accordion title="Returned & Refunded Payments">
    <Card title="Returned Payment" icon="arrow-rotate-left">
      **Category:** Guided

      **Scenario:** 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 correctly

      **Key webhook sequence to verify:**

      | # | Event            | Topic                                           | Expected Status |
      | - | ---------------- | ----------------------------------------------- | --------------- |
      | — | Payment Returned | `transaction.recipient.payment.status.returned` | 1114            |
    </Card>
  </Accordion>
</AccordionGroup>

***

## Webhook Events Reference

<AccordionGroup>
  <Accordion title="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     |
  </Accordion>

  <Accordion title="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                          |
  </Accordion>

  <Accordion title="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) |
  </Accordion>

  <Accordion title="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            |
  </Accordion>

  <Accordion title="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            |
  </Accordion>
</AccordionGroup>