# Payments Platform Overview ## 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. :::note For a larger list of ACH-relevant definitions, visit our [Key Terms page in the Resources](/docs/resources/key-terms) section. ::: ### 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. ::: **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. ::: ### ACH Authorizations Before an ACH payment is initiated through GrailPay's platform, appropriate authorization must be executed as required by regulations governing the ACH network. Authorization is the compliant basis for GrailPay and originators doing payments on the platform to move funds, and serves as the documented record of approval of a payment if any given payment is later questioned by a participating financial institution or Nacha. #### Originator Authorization The originator is the merchant in GrailPay's system initiating a debit on a payer, and must sign GrailPay's ACH Authorization Form before they can begin processing payments. In doing so, the merchant agrees to act as an originator under the Nacha Rules, makes the authorization warranties Nacha requires, and commits to obtaining and retaining a valid authorization for every debit it originates. :::note The merchant ACH Authorization form will be provided during the onboarding process, and must be included in your company documents, explicitly agreed to by each individual merchant before they process payments, and made readily available for review. ::: #### Debit Authorization The merchant acting as the originator of ACH payments is responsible for collecting debit authorization from its payers. This is the per-account authorization that permits the debit. It should capture the payer's identity, the bank account being debited (name on the account, financial institution, account type, routing number, and account number), and the specific payment terms the payer is agreeing to. This is the document that GrailPay must produce for a bank in the event of a Proof of Authorization request if the debit is later disputed by the payer, so a complete account record is not a formality. The full set of account details is what makes the authorization defensible months later. :::note A Proof of Authorization request is a formal Nacha-established bank communication process in which the payer's bank (or the Receiving Depository Financial Institution, or RDFI for short) contacts GrailPay via our sponsor bank (the Originating Depository Financial Institution, or ODFI for short) and requests access to review the payer authorization of a given debit. ::: How high the bar sits depends on who the payer is. A debit on a consumer bank account (WEB ACH) is held to a much stricter standard than a business-to-business debit (CCD). CCD ACH debits move funds between two businesses, and the requirements are correspondingly lighter, with the Proof of Authorization simply requiring the contact information for the payer business. WEB ACH debits pull funds from a consumer's account, and require a higher burden of documented approval to be provided in a Proof of Authorization. For a WEB debit the merchant's terms for ACH payment processing must: - Define the bank account number, routing number, financial institution name, account type, date of authorization, and the reasonable purpose, expected ticket size, and scope of ACH payments. - Run a commercially reasonable fraud-detection system to screen WEB debits and use a commercially reasonable method to authenticate the payer's identity (GrailPay's risk tools satisfy this requirement), and verify that the routing number is valid, which is also performed automatically by GrailPay. - Obtain an authorization in writing, signed or similarly authenticated by the payer (an electronic signature qualifies under the E-SIGN Act). #### More on Proof of Authorization Proof of Authorization, or POA, is the merchant's obligation to show that a debit was authorized when a bank that participated in a payment asks. Two obligations follow. - First, retention: the merchant must keep each authorization for at least two years after it is revoked or terminated, and must be able to hand it over quickly enough for the ODFI to deliver it to the requesting bank within ten business days. - Second, for WEB debits specifically, a copy of the signed authorization alone may not be enough; the merchant should also be able to produce the transaction details and the sales documentation showing what goods or services the debit paid for. A POA request can arrive long after a payment has seemingly been resolved. There are two separate clocks to be aware of: - The 60-day return window. For consumer (WEB) debits, if the payer tells their bank the debit was unauthorized, the bank can generally return it within 60 days of settlement. This is the fast, common path, and it often happens without a POA request at all. - The warranty-claim window. Separately, the Originator warrants to every party in the chain that each debit was properly authorized. Under that warranty, a bank can request POA and pursue a claim well past 60 days: up to two years after settlement for consumer debits, and one year for non-consumer debits. This is why a debit from several months ago can resurface, and why the age of the payment is not, by itself, a defense. Planning for a robust implementation of authorization, both for merchants and payers, is a critical part of designing a reliable integration. GrailPay has additional resources available upon request. --- ## 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 ::: ### 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. ::: ### 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. :::caution 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. ::: ### 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. :::tip You can find additional information on possible [ACH returns in our Resources](/docs/resources/return-codes). ::: ### 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](/docs/resources/transaction-states). ::: --- ## 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 [Environments](/docs/technical/environments) 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). ---