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.
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
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 createdCancel — 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
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
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
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
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
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 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
Card — AVS & CVV Risk Management
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
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 — 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 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
Multi-Party Approval Flows
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 |
| With role changes | payment.status.roles.change firing when party roles are modified during flow |
Returned & Refunded Payments
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
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
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
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
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 |
| Roles Change | transaction.recipient.payment.status.roles.change | — |
Payment Status Events
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 |