--- title: "Execute a single payment using consent" method: POST path: "/payment_initiation/consent/payment/execute" tags: ["plaid"] --- # Execute a single payment using consent `POST /payment_initiation/consent/payment/execute` The `/payment_initiation/consent/payment/execute` endpoint can be used to execute payments using payment consent. ## Request body - PaymentInitiationConsentPaymentExecuteRequest — PaymentInitiationConsentPaymentExecuteRequest defines the request schema for `/payment_initiation/consent/payment/execute` - `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. - `consent_id` string, required — The consent ID. - `amount` PaymentAmount, required — The amount and currency of a payment - `currency` 'GBP' | 'EUR' | 'PLN' | 'SEK' | 'DKK' | 'NOK', required — The ISO-4217 currency code of the payment. For standing orders and payment consents, `"GBP"` must be used. For Poland, Denmark, Sweden and Norway, only the local currency is currently supported. - `value` number, double, required — The amount of the payment. Must contain at most two digits of precision e.g. `1.23`. Minimum accepted value is `1`. - `idempotency_key` string, required — A random key provided by the client, per unique consent payment. Maximum of 128 characters. The API supports idempotency for safely retrying requests without accidentally performing the same operation twice. If a request to execute a consent payment fails due to a network connection error, you can retry the request with the same idempotency key to guarantee that only a single payment is created. If the request was successfully processed, it will prevent any payment that uses the same idempotency key, and was received within 48 hours of the first request, from being processed. - `reference` string, nullable — A reference for the payment. This must be an alphanumeric string with at most 18 characters and must not contain any special characters (since not all institutions support them). If not provided, Plaid will automatically fall back to the reference from consent. In order to track settlement via Payment Confirmation, each payment must have a unique reference. If the reference provided through the API is not unique, Plaid will adjust it. Some institutions may limit the reference to less than 18 characters. If necessary, Plaid will adjust the reference by truncating it to fit the institution's requirements. Both the originally provided and automatically adjusted references (if any) can be found in the `reference` and `adjusted_reference` fields, respectively. - `scope` 'ME_TO_ME' | 'EXTERNAL', nullable — Deprecated, payments will be executed within the type of the consent. A scope of the payment. Must be one of the scopes mentioned in the consent. Optional if the appropriate consent has only one scope defined, required otherwise. - `processing_mode` 'ASYNC' | 'IMMEDIATE' — Decides the mode under which the payment processing should be performed, using `IMMEDIATE` as default. `IMMEDIATE`: Will immediately execute the payment, waiting for a response from the ASPSP before returning the result of the payment initiation. This is ideal for user-present flows. `ASYNC`: Will accept a payment execution request and schedule it for processing, immediately returning the new `payment_id`. Listen for webhooks to obtain real-time updates on the payment status. This is ideal for non user-present flows. ## Response `200` OK - PaymentInitiationConsentPaymentExecuteResponse — PaymentInitiationConsentPaymentExecuteResponse defines the response schema for `/payment_initiation/consent/payment/execute` - `payment_id` string, required — A unique ID identifying the payment - `status` 'PAYMENT_STATUS_INPUT_NEEDED' | 'PAYMENT_STATUS_PROCESSING' | 'PAYMENT_STATUS_INITIATED' | 'PAYMENT_STATUS_COMPLETED' | 'PAYMENT_STATUS_INSUFFICIENT_FUNDS' | 'PAYMENT_STATUS_FAILED' | 'PAYMENT_STATUS_BLOCKED' | 'PAYMENT_STATUS_UNKNOWN' | 'PAYMENT_STATUS_EXECUTED' | 'PAYMENT_STATUS_SETTLED' | 'PAYMENT_STATUS_AUTHORISING' | 'PAYMENT_STATUS_CANCELLED' | 'PAYMENT_STATUS_ESTABLISHED' | 'PAYMENT_STATUS_REJECTED', required — The status of the payment. Core lifecycle statuses: **`PAYMENT_STATUS_INPUT_NEEDED`**: Transitional. The payment is awaiting user input to continue processing. It may re-enter this state if additional input is required. **`PAYMENT_STATUS_AUTHORISING`:** Transitional. The payment is being authorised by the financial institution. It will automatically move on once authorisation completes. **`PAYMENT_STATUS_INITIATED`:** The payment has been authorised and accepted by the financial institution. In many EU markets, `PAYMENT_STATUS_EXECUTED` is not supported, and a payment will remain in `PAYMENT_STATUS_INITIATED` until the funds settle, making this a terminal success state in those cases. A payment in `PAYMENT_STATUS_INITIATED` should be treated as a successfully submitted payment; do not gate downstream processing on reaching `PAYMENT_STATUS_EXECUTED`. For a full explanation of payment statuses and how to handle each, see the [Payment Status guide](https://plaid.com/docs/payment-initiation/payment-status/). **`PAYMENT_STATUS_EXECUTED`: Terminal.** The funds have left the payer's account and the payment is en route to settlement. Note that this status does not confirm that funds have arrived in the recipient's account; do not use it as proof of fund receipt. Support is more common in the UK than in the EU; where unsupported, a successful payment remains in `PAYMENT_STATUS_INITIATED` before settling. When using Plaid Virtual Accounts, `PAYMENT_STATUS_EXECUTED` is not terminal -- the payment will continue to `PAYMENT_STATUS_SETTLED` once funds are available. **`PAYMENT_STATUS_SETTLED`: Terminal.** The funds are available in the recipient's account. Only available to customers using [Plaid Virtual Accounts](https://plaid.com/docs/payment-initiation/virtual-accounts/). Failure statuses: **`PAYMENT_STATUS_INSUFFICIENT_FUNDS`: Terminal.** The payment failed due to insufficient funds. No further retries will succeed until the payer's balance is replenished. **`PAYMENT_STATUS_FAILED`: Terminal (retryable).** The payment could not be initiated due to a system error or outage. Retry once the root cause is resolved. **`PAYMENT_STATUS_BLOCKED`: Terminal (retryable).** The payment was blocked by Plaid (e.g., flagged as risky). Resolve any compliance or risk issues and retry. **`PAYMENT_STATUS_REJECTED`: Terminal.** The payment was rejected by the financial institution. No automatic retry is possible. **`PAYMENT_STATUS_CANCELLED`: Terminal.** The end user cancelled the payment during authorisation. Standing-order statuses: **`PAYMENT_STATUS_ESTABLISHED`: Terminal.** A recurring/standing order has been successfully created. Deprecated (to be removed in a future release): `PAYMENT_STATUS_UNKNOWN`: The payment status is unknown. `PAYMENT_STATUS_PROCESSING`: The payment is currently being processed. `PAYMENT_STATUS_COMPLETED`: Indicates that the standing order has been successfully established. - `request_id` string, required — A unique identifier for the request, which can be used for troubleshooting. This identifier, like all Plaid identifiers, is case sensitive. - `error` PlaidError, nullable — Errors are identified by `error_code` and categorized by `error_type`. Use these in preference to HTTP status codes to identify and handle specific errors. HTTP status codes are set and provide the broadest categorization of errors: 4xx codes are for developer- or user-related errors, and 5xx codes are for Plaid-related errors, and the status will be 2xx in non-error cases. An Item with a non-`null` error object will only be part of an API response when calling `/item/get` to view Item status. Otherwise, error fields will be `null` if no error has occurred; if an error has occurred, an error code will be returned instead. - `error_type` 'INVALID_REQUEST' | 'INVALID_RESULT' | 'INVALID_INPUT' | 'INSTITUTION_ERROR' | 'RATE_LIMIT_EXCEEDED' | 'API_ERROR' | 'ITEM_ERROR' | 'ASSET_REPORT_ERROR' | 'BASE_REPORT_ERROR' | 'RECAPTCHA_ERROR' | 'OAUTH_ERROR' | 'PAYMENT_ERROR' | 'BANK_TRANSFER_ERROR' | 'INCOME_VERIFICATION_ERROR' | 'MICRODEPOSITS_ERROR' | 'SANDBOX_ERROR' | 'PARTNER_ERROR' | 'SIGNAL_ERROR' | 'TRANSACTIONS_ERROR' | 'TRANSACTION_ERROR' | 'TRANSFER_ERROR' | 'CHECK_REPORT_ERROR' | 'CONSUMER_REPORT_ERROR' | 'USER_ERROR' | 'IDEMPOTENCY_ERROR' | 'ASSETS_ERROR' | 'CRA_MONITORING_ERROR' | 'CREDIT_PROFILE_REPORT_ERROR' | 'ENCOMPASS_ERROR' | 'ENRICH_ERROR' | 'FRAUD_INSIGHTS_ERROR' | 'FREDDIE_MAC_ERROR' | 'LINK_DELIVERY_ERROR' | 'PROFILE_ERROR' | 'RECURRING_TRANSACTIONS_ERROR' | 'STATEMENTS_ERROR' | 'TRANSFER_RECURRING_ERROR' | 'TRANSFER_REFUND_ERROR', required — A broad categorization of the error. Safe for programmatic use. - `error_code` string, required — The particular error code. Safe for programmatic use. - `error_code_reason` string, nullable — The specific reason for the error code. Currently, reasons are only supported for OAuth-based item errors; `null` will be returned otherwise. Safe for programmatic use. Possible values: `OAUTH_INVALID_TOKEN`: The user's OAuth connection to this institution has been invalidated. `OAUTH_CONSENT_EXPIRED`: The user's access consent for this OAuth connection to this institution has expired. `OAUTH_USER_REVOKED`: The user's OAuth connection to this institution is invalid because the user revoked their connection. - `error_message` string, required — A developer-friendly representation of the error code. This may change over time and is not safe for programmatic use. - `display_message` string, nullable, required — A user-friendly representation of the error code. `null` if the error is not related to user action. This may change over time and is not safe for programmatic use. - `request_id` string — A unique ID identifying the request, to be used for troubleshooting purposes. This field will be omitted in errors provided by webhooks. - `causes` unknown[] — In this product, a request can pertain to more than one Item. If an error is returned for such a request, `causes` will return an array of errors containing a breakdown of these errors on the individual Item level, if any can be identified. `causes` will be provided for the `error_type` `ASSET_REPORT_ERROR` or `CHECK_REPORT_ERROR`. `causes` will also not be populated inside an error nested within a `warning` object. - unknown - `status` integer, nullable — The HTTP status code associated with the error. This will only be returned in the response body when the error information is provided via a webhook. - `documentation_url` string — The URL of a Plaid documentation page with more information about the error - `suggested_action` string, nullable — Suggested steps for resolving the error - `required_account_subtypes` string[] — A list of the account subtypes that were requested via the `account_filters` parameter in `/link/token/create`. Currently only populated for `NO_ACCOUNTS` errors from Items with `investments_auth` as an enabled product. - `provided_account_subtypes` string[] — A list of the account subtypes that were extracted but did not match the requested subtypes via the `account_filters` parameter in `/link/token/create`. Currently only populated for `NO_ACCOUNTS` errors from Items with `investments_auth` as an enabled product. ## Other responses - `default` — Error response --- [API](https://skmtc.net/plaid/apis/the-plaid-api.md) · [All operations](https://skmtc.net/plaid/apis/the-plaid-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/plaid/the-plaid-api/versions/64c4514ea59b/schema)