External Transactions

External Transactions represent fund movements between your platform accounts and external bank accounts via payment rails such as ACH and WIRE.

These transactions are initiated outside the platform and require matching, validation, and operational review before funds are applied to customer accounts.

This module provides:

• Visibility into incoming/outgoing bank transfers
• Matching and reconciliation workflows
• Operational controls via PayOps and Program Managers

External Transactions are triggered in lieu of any credits or debits received on the routable account details.

Common Use Cases:

• Receiving customer funds via ACH credit or wire transfer
• Processing ACH debits for external collections
• Handling unmatched or partially identified incoming funds
• Performing manual review and reconciliation of transactions

---

How it Works

1. Transaction Initiation (External) Sender initiates transfer using ACH or WIRE Funds are routed to the platform using account details
2. Transaction Creation in System Transaction is recorded as an External Transaction Type is identified based on rail: Type Description ACH Credit Incoming funds ACH Debit Outgoing pull / debit Wire Incoming wire transfer
3. Matching & Validation System attempts to identify the target account Based on: Account number / routing number Memo / reference fields
4. Operational Workflow PayOps Handling PayOps reviews incoming transactions (except ACH Credit) Attempts to match transaction to a valid account

Outcomes:

Match found → proceed for acceptance No match → escalate to Program Manager

ACH Credit transactions are directly escalated to Program Managers

5. Program Manager Actions

Once escalated, Program Managers can take action:

Accept / Reject Transactions

ACH Credit

Accept: /v1/externalTransaction/achCredit/id/{id}/accept Reject: /v1/externalTransaction/achCredit/id/{id}/reject

ACH Debit

Accept: /v1/externalTransaction/achDebit/id/{id}/accept Reject: /v1/externalTransaction/achDebit/id/{id}/reject

Wire

Accept: /v1/externalTransaction/wire/id/{id}/accept

Wire transactions cannot be rejected

Update Transaction (Wire Only) POST /v1/externalTransaction/wire/id/{id}

Used to correct or enrich transaction details before acceptance

Reassign Transaction (ACH Debit Only) POST /v1/externalTransaction/achDebit/id/{id}/reassign

Sends transaction back to PayOps for further review

Transaction Flow / Special Logic Matching depends heavily on reference data quality Missing or incorrect memo details may lead to manual intervention ACH Credit bypasses PayOps → handled directly by PM Wire transactions are final settlement flows → cannot be reversed via reject Transaction Statuses Status Description Reason RECEIVED Transaction received from bank Awaiting processing IN_REVIEW Under PayOps or PM review Matching or validation pending ACCEPTED Transaction successfully processed Account identified REJECTED Transaction rejected (ACH only) Invalid or unmatched REASSIGNED Sent back for further review (ACH Debit only) Requires re-validation Best Practices Practice Description Always include memo/reference details Improves matching accuracy and reduces manual effort Validate account details before sharing Prevents misrouted transactions Monitor transaction statuses actively Helps identify delays or failures early Use correct rails for use case ACH for low-cost transfers, WIRE for urgent/high-value Optional Enhancements

Note: Automatching efficiency improves over time with better data patterns

💡 Tip: Use consistent naming conventions in memo fields for easier reconciliation

⚠️ Constraint:

Wire → No rejection allowed ACH Debit → Supports reassignment ACH Credit → Always PM-driven See Also Creating an Account Direct Transfers using Routable Account Details Transaction APIs

• • • • • 
          

Once funds are received as an external credit or debit, the transaction enters a review and matching workflow before being credited to a customer account.

The PayOps team reviews the incoming transaction and attempts to match it to the appropriate customer account based on the available details.

• If a match is identified, the transaction is accepted and amount is credited or debited to the corresponding account.
• If a match cannot be established, the transaction is escalated to the Program Manager (PM) for further review and action.

ACH Credit transactions are directly escalated to Program Managers and do not go through the PayOps matching process.

Program Manager Actions

When a transaction is escalated, the Program Manager can review the details and take one of the following actions:

1. Accept or Reject the Transaction: Based on the review, the Program Manager can either accept the transaction (to credit the account) or reject it.

   1. ACH Credit

      1. Accept: POST /v1/externalTransaction/achCredit/id/{id}/accept (trainAutomatching can be passed)
      2. Rejec: POST /v1/externalTransaction/achCredit/id/{id}/reject

   2. ACH Debit

      1. Accept: POST /v1/externalTransaction/achDebit/id/{id}/accept (trainAutomatching can be passed)
      2. Reject: POST /v1/externalTransaction/achDebit/id/{id}/reject

   3. Wire

      1. Accept: POST /v1/externalTransaction/wire/id/{id}/accept
      
      

      Wire transactions can only be accepted. They cannot be rejected or reassigned.

2. Update Transaction Details: If additional information is required or corrections are needed, the Program Manager can update the details of a WIRE transaction, before taking action: 
   1. POST /v1/externalTransaction/wire/id/{id}
   
   

   Updation is supported only for Wire transactions

3. Reassign for Further Review: If the transaction requires additional validation or should be handled again by the PayOps team, it can be reassigned: 
   1. POST /v1/externalTransaction/achDebit/id/{id}/reassign
   
   

   Reassignment is supported only for ACH Debit transactions