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

# Payments Platform Overview

> This content is designed as a launching pad to integration, and provides key details relevant to processing ACH with GrailPay and using our Risk Intelligence tools. This context should be helpful to developers and implementation teams before jumping into our technical integration guides and OpenAPI documentation.

## Introduction

Welcome to our Payments Platform Guide, in which we detail how our system interacts with the ACH payment rail, as well as
key considerations around payment behaviors, platform actions, and operational considerations that you should be aware
of as you dive into your integration.

ACH (Automated Clearing House) is an electronic bank payment system that enables consumers and businesses in the United
States to make payments between bank accounts. ACH transactions are processed several times in batch windows set by the
Federal Reserve and according to regulations set by the National Automated Clearing House Association (NACHA).

## What's Included

1. Key Definitions
2. User Onboarding
3. Payment Behavior
4. Payment Speeds
5. Additional Payment Scenarios
6. Operations
7. Testing

***

## Key Definitions

Start here to understand terms important to an ACH transaction.

### Entities

**Federal Reserve**

Serves as the backbone of the ACH network, acting as the central clearing facility for most ACH transactions. The Fed
dictates the processing windows in which transfers are processed, sets the bank holiday schedule that ACH payments abide
by, and manages regulations that determine underlying processing requirements and best practices.

**National Automated Clearing House Association (NACHA)**

The governing body of ACH, NACHA is the regulatory entity managing the administration, development, and governance of
the network. It works closely with the Federal Reserve.

**Originating Depository Financial Institution (ODFI)**

The financial institution that initiates ACH entries at the request of its clients. ODFIs assume the risk and regulatory
responsibility for ACH entries they originate and may set category restrictions, transaction limits, monitoring
thresholds, and reserve requirements on clients, in addition to maintaining certain standards for visibility into
participating businesses and their transaction data.

**Payee**

The business or individual receiving an ACH payment.

**Payer**

The consumer or business authorizing a payment and sending funds for an ACH payment.

**Processor**

Organizations that handle the technical aspects of routing ACH files. GrailPay is an ACH processor.

**Receiving Depository Financial Institution (RDFI)**

The financial institution that receives ACH payments and posts them to the accounts of its clients. RDFIs may have
their own return rate thresholds and monitoring practices.

<Info>
  For a larger list of ACH-relevant definitions, visit our [Key Terms page in the Resources](/docs/resources/key-terms)
  section.
</Info>

### ACH Entry Types

GrailPay offers three ACH entry types: WEB, CCD, and PPD. These different types of ACH have different rulesets applied
by regulators, and require different handling.

**WEB**

Used to debit funds from a **consumer** bank account and requires explicit documented authorization. It is commonly
used for online bill payments, subscription services, and e-commerce purchases.

**CCD**

Used for the transfer of funds between business accounts (B2B payments). It is often used for vendor invoice payments,
corporate disbursements, and rent and utility payments.

**PPD**

Used for consumer push payments, commonly for direct deposit of payroll.

**Summary of ACH Entry Types**

| Consideration                        | WEB                                                                                     | CCD                                  | PPD                                                                                     |
| ------------------------------------ | --------------------------------------------------------------------------------------- | ------------------------------------ | --------------------------------------------------------------------------------------- |
| Fraud risk                           | High                                                                                    | Medium                               | Medium                                                                                  |
| Applicable return timeframes         | Most returns come in 2 banking days, with some returns having a 60 day allowable window | 2 banking days, some rare exceptions | Most returns come in 2 banking days, with some returns having a 60 day allowable window |
| Bank account validation requirements | Required                                                                                | Recommended                          | Recommended                                                                             |

***

## User Onboarding

GrailPay supports three user types for participation in payments on our platform: Merchants, Businesses, and People. Each
has a dedicated API endpoint for onboarding, and requires slightly different treatment for successful onboarding and
management.

**Merchants**

These are companies that undergo our KYB verification, requiring specific information on the underlying business and its
owners. GrailPay requires that at least one side of every payment be KYB'd, meaning that a merchant can be thought of as
the anchor of an ACH payment on our platform.

<Tip>
  **KYB (Know Your Business)**

  This is the process of identifying and verifying the identity of a corporate customer to assess risk and ensure
  compliance with applicable regulations. This involves collecting and verifying documents related to a business's
  legal structure and ownership, as well as checking for adverse media, sanctions, or high-risk affiliations. The goal
  is to prevent financial crimes, by ensuring we do not process payments for illegitimate or high-risk entities.
</Tip>

**Businesses**

These are companies that do not undergo our KYB verification. Onboarding a new company to GrailPay as a business rather
than a merchant facilitates B2B payments without requiring KYB on both entities. This payment flow creates a CCD ACH.

**People**

These are individuals who are added to participate in ACH payments to businesses. This payment flow creates WEB ACHs.

<Note>
  **Bank account validation**

  GrailPay supports verification of bank accounts at the time you onboard users. This is a critical step in reducing the
  risk of ACH payment failures due to preventable operational causes like typos during entry or outdated routing
  numbers. Our [Account Intelligence](/docs/risk/bank-accounts/account-intelligence) offering, a foundational tool within
  our Risk Intelligence suite, provides a risk score assessing the validity of a bank account and its ability to
  successfully transact ACH payments.
</Note>

***

## Payment Behavior

ACH follows consistent behavioral pathways from payer to payee. GrailPay defines the movement of funds with an ACH
payment as a Transaction.

Every Transaction has two legs, or, in ACH terms, originations. The first leg is the Transaction Capture, sometimes
known as the debit, or pay-in, and the second leg is the payout, or credit.

<Note>
  **Payment = Transaction Capture + Payout**

  * Transaction Capture = first origination or debit
  * Payout = second origination or credit
</Note>

### Transaction Capture

This is the initiation of the funds' movement and tracks the related information regarding the debit side of the
transfer, taking the funds from the payer. GrailPay's webhooks provide numerous real-time status updates on the
debit as it experiences event updates through the processing lifecycle.

**Transaction Started**

This event is fired when the Transaction is created within our system, but the ACH has not begun to process yet. This
should occur in a short time following the call to our API to create the transfer of funds.

**Transaction Capture Started**

This event is fired when an ACH debit has been successfully initiated on the related transaction. It indicates the funds
capture process has begun from the payer's bank account.

**Transaction Failed**

This event is fired if the transaction fails during any stage of processing, whether due to account issues, validation
errors, or ACH Return Codes. Most of these will be due to ACH Return Codes as most of our validation checks occur
prior to the transaction being created.

**Transaction Completed**

This event is fired when the debit side of the transfer has completed. This means that the debit from the payer has
successfully settled and we are initiating the transfer of those funds to the payee.

**Transaction Canceled**

This event is fired when a transaction is canceled and confirms that no funds will be captured or disbursed. There
are limitations on the allowable time frame to cancel a transaction. Once we have processed a debit, indicating that the
bank has received and accepted the ACH entry, a cancellation will not be accepted by the system.

<Note>
  **Transaction monitoring**

  GrailPay supports active monitoring of individual transactions with [Transaction Intelligence](/docs/risk/transactions/transaction-intelligence).
  This functionality allows you to assess the likelihood that a specific ACH transaction from a payer will successfully
  settle, and uses forensic analysis to predict a transaction's risk at that moment in time.
</Note>

### Payout

Once the debit of the ACH has completed, the payout is created, representing the credit side of the transfer, which is
us moving the funds to the payee.

<Warning>
  When processing ACH payments, the participating financial institutions ultimately dictate the exact timing at which
  funds are moved from and into accounts. This means that while an ACH entry may have been processed successfully by
  GrailPay and indicate settlement (meaning the bank has received the file), the action may not yet have triggered
  actual funds availability.
</Warning>

### Refunds

In the event that either the payer or payee determines that the intentional reversal of a successful ACH payment is
desired, a refund may be issued. If a refund is decided upon before a payout is complete, the refund can be created,
and will be processed as soon as the payout is settled.

***

## Payment Speeds

GrailPay offers multiple options for the speed at which payments can move. The processing of ACH payments are dictated
by pre-determined processing windows set by the Federal Reserve. This system allows for payments to be initiated
throughout the day before being processed in the next window.

### Standard ACH

GrailPay processes Standard ACH on a four day settlement schedule, meaning the payout occurs four banking days after
the payment initiation. Actual funds availability to the payee will ultimately be determined by their financial
institution's internal policies.

### Fast ACH

GrailPay processes Fast ACH on a same or next day settlement schedule, depending on what time the payment is initiated.
Actual funds availability to the payee will ultimately be determined by their financial institution's internal policies.

***

## Additional Payment Scenarios

### ACH Returns

ACH payments can fail for a variety of reasons including things like a closed bank account, a debit-blocked bank account,
insufficient funds in the payer's bank account, and even sanctions freezes on bank accounts.

ACH returns are unique in that they occur *after* the initial payment initiation. The overwhelming majority of returns
occur within two banking days of the initial payment initiation, and for B2B ACHs (CCD), are generally limited to this
timeframe. Returns on consumer, or WEB ACHs, also typically occur within two days, but do have a 60 day allowable time
frame from payment initiation for payer disputes.

When doing Standard ACH (four day settlement), returns are typically triggered before a payout has occurred, in which
case the funds from the credit are seamlessly returned to the payer. When doing Fast ACH (same/next-day settlement), it
is more common to see returns triggered after the payout has occurred. In this scenario, GrailPay's system automatically
initiates a clawback, which debits the payee bank account to offset the funds that went back to the payer due to the
return.

<Check>
  You can find additional information on possible [ACH returns in our Resources](../resources/return-codes).
</Check>

### Notice of Change (NOC)

Occasionally in the course of processing ACH, a Receiving Depository Financial Institution (RDFI) will issue a Notice
of Change, or NOC. These communicate when an ACH entry is outdated or incorrect. The RDFI sends the NOC to the Originating
Depository Financial Institution (ODFI) to notify them of the erroneous account information, in which case we are allowed
six days to update the bank account information.

In most cases when a NOC is issued, an ACH payment will still process successfully. GrailPay will communicate the receipt
of NOCs when they are received, and update the relevant bank account information as is required.

### Clawback

A clawback is triggered automatically when an ACH return occurs after the payout has been processed. In this scenario,
the return has already reversed the funds back to the payer, and the clawback is debiting the merchant bank account to
zero out the difference.

### Reverse Payout

These occur when the payee bank account is not active, or in some rare scenarios, cannot be credited. In such instances,
the funds are sent back to the payer.

<Tip>
  For a full list of possible ACH payment behaviors and their associated GrailPay events and statuses, review our
  dedicated [Resource page](../resources/transaction-states).
</Tip>

***

## Operations

To ensure the smooth and efficient management of an ACH payments program, GrailPay implements basic transaction rules and
allowable payment volumes within given time frames. These are tailored to the specific requirements of each client ACH
program, and are set during onboarding.

### Origination Limit

Your origination limit is the maximum total allowable amount of ACH payment volume, in dollars, during a rolling 24 hour
time period. **This limit should be actively monitored with internal logic and tooling at all times** to ensure a
disruption-free experience. Failure to do so may result in unexpected payment failures that will require manual
correction.

***

## Testing

To test your integration, connect to GrailPay's sandbox environment at `https://api-sandbox.grailpay.com`. For full
details on environment configuration, refer to our [Sandbox Environment](/docs/technical/sandbox-environment) guide.

### Bank Accounts

When creating people, businesses, or merchants in the sandbox, you can simulate bank accounts using a random 12-digit
account number and one of the following test routing numbers:

* `226078036`
* `221979363`

This setup allows you to test your full integration flow — including onboarding, transactions, and ACH processing —
without interacting with real financial institutions.

### Social Security Numbers (SSNs)

When testing in the sandbox environment, Social Security Numbers (SSNs) must follow specific formatting rules to be
considered valid. The SSN:

* **Cannot** begin with `"000"` or any value in the range `"900–999"`
* **Cannot** have `"00"` as the middle two digits
* **Cannot** end in `"0000"`

Any other valid 9-digit SSN format outside of these constraints is acceptable for testing purposes.

***

## Questions?

If you're encountering any issues, please reach out to [support@grailpay.com](mailto:support@grailpay.com).

***