Overview

Embedded Payments enables platforms and their clients to make payouts to themselves or external parties. After the setup is completed, users can send funds to their selected bank account using any available payment method. Platforms can choose any of the payment methods based on their requirements. Platforms or clients must be configured for a particular payment method before initiating payouts.

Payment methods

 The table lists supported payment types, currencies, cut-off times, settlement periods and transaction limits.

Registered and unregistered payment party

You can make payouts to registered or unregistered payment parties. Registering a payment party lets you save their details, including name, address, and payment instrument information. Once registered, use a unique ID for payouts. If you don’t register, provide party and payment instrument details each time you make a payout. Platforms can register their payment party via the recipient resource. If you prefer not to register, simply provide the necessary party and payment instrument details like the account holder and bank account details at the time of payout. To register, see External accounts.

Allowed payout accounts

Payout permissions depend on the account type. The table shows which external payment parties or payees are eligible for payouts from each account type:

How to make a payout

You can make a payout after transferring funds to an eligible account.

1. Use GET /accounts/{id}/balances to check that the account balance of Embedded Payments account is updated.
2. Use POST /transactions to make a payout from this account to the external bank account.

To make the payment, you need to include:

• Your client’s recipientId (linked account).
• Your client’s Embedded Payments account ID as debtorAccountId (use GET /accounts to retrieve).
• Transaction type: "ACH", "RTP" (Real Time Payments), "WIRE" or "CARD" (Push to Card).
  • You must make sure that the payee is set up with the correct details for wire and RTP payments, if you prefer to use these methods for a registered payees.  
  • For an unregistered payee, provide the necessary party and payment instrument details like the account holder and bank account details at the time of payout.
• Make sure your client’s linked account is set up for wire and RTP payments, if needed.
• Amount to be paid.
• Currency (always USD)
• The transactionReferenceID is your reference number for this transaction. It must be unique for every payment.
• Some payment methods require  specific field like localInstrumentCode for ACH.
  • localInstrumentCode: A Standard Entry Class (SEC) code is a three-letter identifier established by NACHA to specify how an ACH transaction is authorized. Businesses using J.P. Morgan Embedded Payments must select the correct SEC code for each debit transaction to ensure compliance with ACH direct debit rules and maintain proper authorization records for potential disputes. J.P. Morgan Embedded Payments currently supports four types of SEC codes for ACH debits such as "CCD", "PPD", "WEB" and "TEL". Mandate requirements differ based on the type of authorization collected. Businesses should consult a professional for guidance on their specific obligations, as this information is intended for general reference only. 
  • When you use v2/transactions, we default to "PPD" for consumer bank accounts, "CCD" for business bank accounts, and "WEB" for direct debit. If you do not specify a mandate collection method, we apply these defaults. When you use v3/transactions, you must provide a value for localInstrumentCode.

Following are the general guidance on the minimum required information for each payment method. For more details, See API references.

When you make a payment, we send you a notification so you can track the payout. If you need to check the payment status, use the GET /transactions endpoint.