1:37
Account-to-Account (A2A) payments are transfers made between two accounts owned by the same individual or business. (Note: Other payment industry participants define A2A transactions in a way that includes more payment types, but we like to keep things simple for our integrators.)
The two accounts in an A2A transaction may be held at the same bank or credit union or at different financial institutions (FIs). As long as both accounts are owned by the person initiating the payment, it’s still considered an A2A transaction.
A2A transactions look at lot like any other transaction type, but they present different risks and challenges, since there is only a single party representing both halves of the transaction.
We process A2A payments through two products: iPay and Payrailz. In addition to A2A, iPay and Payrailz both allow consumers and businesses to make bill payments, Person-to-Person (P2P) payments, and loan payments. They use a variety of rails to deliver payments, including checks, virtual cards, ACH, the RTP® Network, and FedNow® Service.
For A2A payments, iPay and Payrailz fulfill them using one of the following methods:
We use our direct connection to the financial institution’s core system to post both the credit and debit to the sender’s accounts.
We leverage an instant payments rail such as The Clearing House RTP® Network or the FedNow Service® to post the outbound (credit) entry to accounts at other banks or credit unions.
We originate Automated Clearing House (ACH) transactions to post the outbound (credit) portion of payments to an account at a financial institution without connections to an instant payments network.
We are currently engaged in a project to merge iPay and Payrailz into a holistic money movement platform. Regardless of which product you integrate to, you will be able to take advantage of the new platforms capabilities once they become available.
Integration to either product is simple, but integrators acting on behalf of a financial institution should leverage the APIs associated with the product in use by that institution. For instance, if you are integrating on behalf of an FI that is using iPay, you should integrate using the iPay APIs. If you are integrating on behalf of a financial institution that is using Payrailz, you should integrate using the Payrailz APIs. Both products are effective, but there are some restrictions.
A2A transactions can occur in either of these scenarios:
A user transfers funds between two accounts at the home financial institution*.
A user transfer funds from an account at their home financial institution* to an account at another financial institution.
Payrailz can accommodate either type of transaction, but iPay can only handle the second type—funds transferred from the home financial institution* to the user’s account at another bank or credit union. It is not built to provide transfers between two accounts at the user’s home financial institution*.
*For the purposes of this discussion, the user’s “home financial institution” is the institution that is using iPay or Payrailz. Put another way, it is the institution on whose behalf you are integrating to our solutions.