Create a recurring transfer

POST /transfer/recurring/create

Use the /transfer/recurring/create endpoint to initiate a new recurring transfer. This capability is not currently supported for Transfer UI or Platform Payments (beta) customers.

Request Body

Required

Defines the request schema for /transfer/recurring/create

Parameters

client_id
string
Your Plaid API client_id. The client_id is required and may be provided either in the PLAID-CLIENT-ID header or as part of a request body.
secret
string
Your Plaid API secret. The secret is required and may be provided either in the PLAID-SECRET header or as part of a request body.
access_token
required, string
The Plaid access_token for the account that will be debited or credited.
idempotency_key
required, string
A random key provided by the client, per unique recurring transfer. Maximum of 50 characters. The API supports idempotency for safely retrying requests without accidentally performing the same operation twice. For example, if a request to create a recurring fails due to a network connection error, you can retry the request with the same idempotency key to guarantee that only a single recurring transfer is created.
account_id
required, string
The Plaid account_id corresponding to the end-user account that will be debited or credited.
funding_account_id
string
Specify the account used to fund the transfer. Customers can find a list of funding_account_ids in the Accounts page of your Plaid Dashboard, under the “Account ID” column. If this field is left blank, it will default to the default funding_account_id specified during onboarding.
type
required, string
The type of transfer. This will be either debit or credit. A debit indicates a transfer of money into the origination account; a credit indicates a transfer of money out of the origination account.
network
required, string
Networks eligible for recurring transfers.
ach_class
string
Specifies the use case of the transfer. Required for transfers on an ACH network. For more details, see ACH SEC codes. Codes supported for credits: ccd, ppd Codes supported for debits: ccd, tel, web "ccd" - Corporate Credit or Debit - fund transfer between two corporate bank accounts "ppd" - Prearranged Payment or Deposit - The transfer is part of a pre-existing relationship with a consumer. Authorization was obtained in writing either in person or via an electronic document signing, e.g. Docusign, by the consumer. Can be used for credits or debits. "web" - Internet-Initiated Entry. The transfer debits a consumer’s bank account. Authorization from the consumer is obtained over the Internet (e.g. a web or mobile application). Can be used for single debits or recurring debits. "tel" - Telephone-Initiated Entry. The transfer debits a consumer. Debit authorization has been received orally over the telephone via a recorded call.
amount
required, string
The amount of the transfer (decimal string with two digits of precision e.g. “10.00”). When calling /transfer/authorization/create, specify the maximum amount to authorize. When calling /transfer/create, specify the exact amount of the transfer, up to a maximum of the amount authorized. If this field is left blank when calling /transfer/create, the maximum amount authorized in the authorization_id will be sent.
user_present
boolean
If the end user is initiating the specific transfer themselves via an interactive UI, this should be true; for automatic recurring payments where the end user is not actually initiating each individual transfer, it should be false.
iso_currency_code
string
The currency of the transfer amount. The default value is “USD”.
description
required, string
The description of the recurring transfer.
test_clock_id
string
Plaid’s unique identifier for a test clock. This field may only be used when using the sandbox environment. If provided, the created recurring_transfer is associated with the test_clock. New originations are automatically generated when the associated test_clock advances. For more details, see Simulating recurring transfers.
schedule
required, object
The schedule that the recurring transfer will be executed on.
interval_unit
required, string
The unit of the recurring interval.
interval_count
required, integer
The number of recurring interval_units between originations. The recurring interval (before holiday adjustment) is calculated by multiplying interval_unit and interval_count. For example, to schedule a recurring transfer which originates once every two weeks, set interval_unit = week and interval_count = 2.
interval_execution_day
required, integer
The day of the interval on which to schedule the transfer. If the interval_unit is week, interval_execution_day should be an integer from 1 (Monday) to 5 (Friday). If the interval_unit is month, interval_execution_day should be an integer indicating which day of the month to make the transfer on. Integers from 1 to 28 can be used to make a transfer on that day of the month. Negative integers from -1 to -5 can be used to make a transfer relative to the end of the month. To make a transfer on the last day of the month, use -1; to make the transfer on the second-to-last day, use -2, and so on. The transfer will be originated on the next available banking day if the designated day is a non banking day.
start_date
required, string
A date in ISO 8601 format (YYYY-MM-DD). The recurring transfer will begin on the first interval_execution_day on or after the start_date. For rtp recurring transfers, start_date must be in the future. Otherwise, if the first interval_execution_day on or after the start date is also the same day that /transfer/recurring/create was called, the bank may make the first payment on that day, but it is not guaranteed to do so.
end_date
string
A date in ISO 8601 format (YYYY-MM-DD). The recurring transfer will end on the last interval_execution_day on or before the end_date. If the interval_execution_day between the start date and the end date (inclusive) is also the same day that /transfer/recurring/create was called, the bank may make a payment on that day, but it is not guaranteed to do so.
user
required, object
The legal name and other information for the account holder.
legal_name
required, string
The user’s legal name.
phone_number
string
The user’s phone number. Phone number input may be validated against valid number ranges; number strings that do not match a real-world phone numbering scheme may cause the request to fail, even in the Sandbox test environment.
email_address
string
The user’s email address.
address
object
The address associated with the account holder.
street
string
The street number and name (i.e., “100 Market St.”).
city
string
Ex. “San Francisco”
region
string
The state or province (e.g., “CA”).
postal_code
string
The postal code (e.g., “94103”).
country
string
A two-letter country code (e.g., “US”).
device
object
Information about the device being used to initiate the authorization.
ip_address
required, string
The IP address of the device being used to initiate the authorization.
user_agent
required, string
The user agent of the device being used to initiate the authorization.

Response

Defines the response schema for /transfer/recurring/create

Response Properties

recurring_transfer
object
Represents a recurring transfer within the Transfers API.
decision
required, string
A decision regarding the proposed transfer. approved – The proposed transfer has received the end user’s consent and has been approved for processing by Plaid. The decision_rationale field is set if Plaid was unable to fetch the account information. You may proceed with the transfer, but further review is recommended. Refer to the code field in the decision_rationale object for details. declined – Plaid reviewed the proposed transfer and declined processing. Refer to the code field in the decision_rationale object for details. user_action_required – An action is required before Plaid can assess the transfer risk and make a decision. The most common scenario is to update authentication for an Item. To complete the required action, initialize Link by setting transfer.authorization_id in the request of /link/token/create. After Link flow is completed, you may re-attempt the authorization request.
decision_rationale
object
The rationale for Plaid’s decision regarding a proposed transfer. It is always set for declined decisions, and may or may not be null for approved decisions.
code
required, string
A code representing the rationale for approving or declining the proposed transfer. If the rationale_code is null, the transfer passed the authorization check. Any non-null value for an approved transfer indicates that the the authorization check could not be run and that you should perform your own risk assessment on the transfer. The code will indicate why the check could not be run. Possible values for an approved transfer are: MANUALLY_VERIFIED_ITEM – Item created via a manual entry flow (i.e. Same Day Micro-deposit, Instant Micro-deposit, or database-based verification), limited information available. ITEM_LOGIN_REQUIRED – Unable to collect the account information due to Item staleness. Can be resolved by using Link and setting transfer.authorization_id in the request to /link/token/create. MIGRATED_ACCOUNT_ITEM - Item created via /transfer/migrate_account endpoint, limited information available. ERROR – Unable to collect the account information due to an unspecified error. The following codes indicate that the authorization decision was declined: NSF – Transaction likely to result in a return due to insufficient funds. RISK - Transaction is high-risk. TRANSFER_LIMIT_REACHED - One or several transfer limits are reached, e.g. monthly transfer limit. Check the accompanying description field to understand which limit has been reached.
description
required, string
A human-readable description of the code associated with a transfer approval or transfer decline.
request_id
required, string
A unique identifier for the request, which can be used for troubleshooting. This identifier, like all Plaid identifiers, is case sensitive.