Once an account is successfully created and active, it can be used to receive funds directly from external bank accounts using supported payment rails such as ACH and WIRE.

Each account is assigned routable account details, which are available in the response of the GET v1/customer/id/{id}/account/id/{id} API, under the routableAccount object:

How it Works

• Retrieve the account details using the GET Account API
• Share the appropriate ACH or WIRE details with the sender
• The sender initiates a transfer via ACH or WIRE
• Funds are received as an external credit in the account once processed

These transactions originate outside the platform and are processed once received via banking rails.

Important Notes

• Use ACH fields (accountNumber, routingNumber) for ACH transfers
• Use WIRE fields (wireAccountNumber, wireRoutingNumber) for wire transfers
• Include memo fields where possible to simplify reconciliation
• Ensure the account is in an ACTIVE state before sharing details

Handling External Transactions

All incoming or outgoing transfers via ACH/WIRE are processed as External Transactions within the system.

Refer to the External Transactions page for detailed information on PayOps and Program Manager workflows for handling these 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

   • The system attempts to identify the target account based on available transaction details
   • Matching is performed using:
     • Account number and routing number
     • Memo / reference fields
     • Historical matching patterns (if available)
     
     

   Matching accuracy improves over time as the system learns from previously accepted transactions.

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: Transactions that cannot be automatically matched are escalated for further review and routed for manual resolution.

Program Manager Actions

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

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

• ACH Credit
  • Accept: POST /v1/externalTransaction/achCredit/id/{id}/accept
  • Rejec: POST /v1/externalTransaction/achCredit/id/{id}/reject
  
  

  You can pass trainAutomatching=true while accepting a transaction to train the system for future matching of similar transactions.

• ACH Debit
  • Accept: POST /v1/externalTransaction/achDebit/id/{id}/accept
  • Reject: POST /v1/externalTransaction/achDebit/id/{id}/reject
  
  

  You can pass trainAutomatching=true while accepting a transaction to train the system for future matching of similar transactions.

• Wire
  • Accept: POST /v1/externalTransaction/wire/id/{id}/accept
  
  

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

b. 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: 

• POST /v1/externalTransaction/wire/id/{id}

Updation is supported only for Wire transactions

c. Reassign for Further Review: If the transaction requires additional validation or should be handled again by the PayOps team, it can be reassigned: 

• POST /v1/externalTransaction/achDebit/id/{id}/reassign

Reassignment is supported only for ACH Debit transactions

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 Program Manager
• Wire transactions are final settlement flows → cannot be reversed via reject

---

Transaction Statuses

---

Best Practices

Note: Automatching efficiency improves over time with better data patterns

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