External Credits represent inbound funds received from external banking rails and routed into the platform for matching, review, and posting to customer accounts. This page helps you understand how inbound ACH credits, wire credits, and applicable check-based credit activity are recorded, reviewed, and applied after funds arrive through external rails.

External Credit Transactions are created when funds are received using routable account details or supported deposit workflows. Before funds are applied to a customer account, the system attempts to identify the correct destination account and determine whether operational review is required.

Roles involved in External Credit review

External Credit handling may involve operational review. The following roles may appear in this workflow:

• Payment Operations (PayOps): The operational review function that supports payment operations, matching, exception handling, and reconciliation.
• Program Manager: The organization or program entity configured in PCE to manage a financial program. Customers, accounts, products, transaction rules, permissions, and review workflows operate within the Program Manager’s ecosystem.

If your integration exposes External Credit status to end users, avoid showing funds as available until the credit has been accepted and posted to the target account.

How it Works

1. Sender initiates the transfer externally
   The sender starts the transfer from their bank or financial institution using supported rail details, such as ACH or Wire account information.

2. Funds are received by the platform
   The platform receives the inbound credit and records it as an External Credit for visibility, matching, and operational handling.

3. System attempts matching
   The system attempts to match the inbound credit to a target account using available transaction details, such as account number, routing number, memo, reference information, and configured matching rules.

4. Credit enters review when needed
   If the credit cannot be confidently matched or requires manual action, it remains in review until the Program Manager accepts or rejects it.

5. Funds are applied after acceptance
   Once the External Credit is accepted, the funds are credited to the identified customer account.

6. Track the credit through status changes
   Use webhooks as the recommended production pattern for status updates. Use list or retrieve APIs as a fallback for reconciliation and operational dashboards.

External Credit Types

External Credits can be created from different inbound rail or deposit workflows.

Confirm the exact API type values returned for each External Credit type in the API response. Human-readable labels such as “ACH Credit” and “Wire Credit” should not be treated as API enum values unless confirmed in the API Reference.

Matching and Review

When an External Credit is received, the system uses rule-based matching to identify the target account.

Matching may use:

• account number
• routing number
• wire routing details, where applicable
• memo or reference fields
• configured matching rules from previously accepted transactions, when training is used

Matching is rule-based. It is not a machine-learning workflow. Missing, incorrect, or inconsistent memo details may cause the credit to require manual review.

Funds during review

While an External Credit is under review, the funds have been received through the external rail but are not applied to the customer’s account until the transaction in-review is accepted.

The sending party may see the transfer as sent or completed from their bank’s perspective, while the platform still shows the credit in review. The received funds may require matching or operational review before they become available.

Operational Workflow

External Credits follow this operational flow:

External sender initiates transfer
        ↓
Funds received by platform
        ↓
Match not found (system unable to identify the account to be credited)
        ↓
External Credit Transaction created 
        ↓
System attempts rule-based matching
        ↓
┌───────────────────────────────┬───────────────────────────────┐
│ Match found                   │ Match missing or uncertain     │
│ Proceed to review / action    │ Escalate for Program Manager   │
└───────────────────────────────┴───────────────────────────────┘
        ↓
Program Manager accepts or rejects
        ↓
Funds are posted or credit is rejected

Partial or uncertain matches

A credit may require review even when some details match. For example:

• account number matches, but memo/reference information is missing
• routing details match, but account details are incomplete
• memo is present, but does not match the expected format
• sender information differs from expected values
• check-based credit details require reconciliation

In these cases, the credit should remain in review until the Program Manager confirms the correct action.

Program Manager Actions

When an External Credit requires action, the Program Manager can review the details and take the supported action for the rail.

ACH Credit

ACH Credits can be accepted or rejected.

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

Use accept when the target account has been identified and funds should be credited. Use reject when the ACH Credit is invalid, unmatched, or should not be applied to the account.

Automatching training

When accepting an ACH Credit, you can pass trainAutomatching=true to help the system apply the same rule-based matching pattern to similar future credits.

Key points of automatching training ->

• Passed in POST /v1/externalTransaction/achCredit/id/{id}/accept
• system is trained on the basis of following transaction parameters:
  • company.name
  • company.id
  • routableAccount.accountNumber
  • odfiRoutingNumber

If automatching is trained incorrectly, contact the PCE PayOps team to deactivate the matching rule and prevent future incorrect matches.

Before enabling training, confirm:

• where trainAutomatching is passed in the request
• what fields are used for future matching
• whether training is scoped to the account, customer, or program
• whether trained matching rules can be reviewed or removed
• whether the current transaction is a repeatable pattern or a one-time exception

Use automatching training carefully. Incorrectly training a one-time exception may cause future credits with similar details to be matched incorrectly.

Wire Credit

Wire Credits can be updated and accepted.

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

Use update when additional information is required or transaction details need correction before acceptance.

Wire Credits cannot be rejected through the External Transaction reject workflow. Wires are final settlement flows in this workflow. If a wire is received for the wrong customer, cannot be matched, or requires fraud or compliance handling, follow the operational escalation process defined for your program.

Confirm the operational return, recall, or escalation process for unmatched or suspicious Wire Credits with your PayOps or Program Manager team.

Find and Track External Credits

Before accepting or rejecting an External Credit, your system needs the External Credit identifier.

External Credit IDs may be obtained from:

• webhook payloads, when external transaction events are enabled
• list or search API responses
• operational review dashboards, where applicable

Add the External Transaction list endpoint here once confirmed, including supported filters for status, type, date range, customer, and account.

Recommended filters for operational dashboards include:

• status = IN_REVIEW
• credit type or rail
• created date range
• customer identifier
• account identifier
• amount

For production integrations, use webhooks as the primary notification mechanism and use polling only as a fallback or reconciliation process.

See Webhook Event Types for available webhook events.

Add the exact External Credit webhook event names here once confirmed.

External Credit Lifecycle

External Credits move through a review lifecycle before funds are applied to the customer account.

Wire Credits cannot be rejected through the External Transaction reject workflow. Use the operational escalation process for unmatched or suspicious Wire Credits.

For a detailed state transition reference, create or link an External Credit Lifecycle page.

Error Handling

External Credit actions may fail because of validation errors, missing required details, unsupported status transitions, permission issues, or rail-specific constraints.

For error codes and resolution guidance, see External Transaction Handling Error Codes.

Common error scenarios include:

• attempting to accept an External Credit that is not in a valid review state
• attempting to reject a Wire Credit
• missing or invalid transaction identifier
• insufficient permissions for the requested action
• invalid or incomplete update details for a Wire Credit
• attempting to train automatching on a transaction that is not eligible

Best Practices