Plaid Payment Initiation mock API and live sandbox

A WireMock simulation of Plaid's REST API — covering payment recipients, payment creation and tracking, sweeping consents, refunds, and payment profiles.

Vendor: Plaid
Functionality: Payments, consents, recipients
Spec version: 2020-09-14_1.688.6
Endpoints: 17
Stubs: 21
Protocol: REST
Validation: AI-validated

Live sandbox (no signup or API key needed)

A shared instance of this template runs on a public endpoint — call it right now from curl, an SDK, or an AI agent. Responses are fixed examples and behavior can't be changed; rate limits apply.

Jump to the endpoints ↓

Use the full template in WireMock Cloud

Run this template as a mock API in WireMock Cloud for a private instance you control — edit stubs, add stateful scenarios, use dynamic response templating, and inspect requests in the log.

Open in WireMock Cloud (free) →

Base URL: https://81l7q.wiremockapi.cloud

Endpoints

POST Create - /payment_initiation/recipient/create

curl -s -X POST 'https://81l7q.wiremockapi.cloud/payment_initiation/recipient/create' \
  -H 'Content-Type: application/json' \
  -d '{}'

POST List - /payment_initiation/recipient/list

curl -s -X POST 'https://81l7q.wiremockapi.cloud/payment_initiation/recipient/list' \
  -H 'Content-Type: application/json' \
  -d '{}'

POST Create - /payment_initiation/payment/create

curl -s -X POST 'https://81l7q.wiremockapi.cloud/payment_initiation/payment/create' \
  -H 'Content-Type: application/json' \
  -d '{}'

Spec catalog — The Plaid API (2020-09-14_1.688.6) · 17 endpoints

Method	Path	Summary
POST	`/payment_initiation/consent/create`	Create payment consent
POST	`/payment_initiation/consent/get`	Get payment consent
POST	`/payment_initiation/consent/payment/execute`	Execute a single payment using consent
POST	`/payment_initiation/consent/revoke`	Revoke payment consent
POST	`/payment_initiation/payment/create`	Create a payment
POST	`/payment_initiation/payment/get`	Get payment details
POST	`/payment_initiation/payment/list`	List payments
POST	`/payment_initiation/payment/reverse`	Reverse an existing payment
POST	`/payment_initiation/payment/token/create`	Create payment token
POST	`/payment_initiation/recipient/create`	Create payment recipient
POST	`/payment_initiation/recipient/get`	Get payment recipient
POST	`/payment_initiation/recipient/list`	List payment recipients
POST	`/payment_profile/create`	Create payment profile
POST	`/payment_profile/get`	Get payment profile
POST	`/payment_profile/remove`	Remove payment profile
POST	`/sandbox/payment_profile/reset_login`	Reset the login of a Payment Profile
POST	`/sandbox/payment/simulate`	Simulate a payment event in Sandbox

Unauthenticated WireMock Cloud demo sandbox for Plaid — not an official Plaid sandbox, and it returns simulated example data only.

Customize in WireMock Cloud (Free) Talk to an expert

What's inside the Payment Initiation template

Seventeen endpoints model Plaid's UK-and-Europe payments product, and the record-keeping is selective in an instructive way: ids are stateful, bodies are not. Create a recipient, a payment, or a consent and the id is registered — the get and list routes recognize it from then on, while an id nobody registered draws PAYMENT_NOT_FOUND. The bodies attached to those ids stay canonical: every recipient reads back as the Wonder Wallet fixture with its London address and GB IBAN, every payment as the hundred-pound Account Funding entry with BACS details. Between create and get, a payment's status steps from PAYMENT_STATUS_INPUT_NEEDED to PAYMENT_STATUS_INITIATED — the exact transition /sandbox/payment/simulate reports.

Recipients — create, gated get, and a list that grows with each registration
Payments — registered payment ids, the INPUT_NEEDED-to-INITIATED step, and BACS-flavored detail bodies
Consents — an AUTHORISED sweeping consent with validity-window, per-payment, and periodic constraints
Refunds & tokens — the reverse route's INITIATED refund and single-use payment token minting
Payment profiles — profile token creation and a READY status read
Sandbox controls — the simulate route reporting an old-to-new status transition

Example implementation using plaid-python

plaid-python runs the full recipient-then-payment sequence against the sandbox with only its host changed:

The two printed statuses tell the product's story in two lines: create answers INPUT_NEEDED — the point where a real payment waits on the user's bank authorization — and the follow-up read reports INITIATED, as though that authorization happened between your calls. A checkout's post-redirect polling gets both sides of the gap from one deterministic sequence.

The states that earn payments code its review sign-off — REJECTED, INSUFFICIENT_FUNDS, a consent expiring mid-series — belong in a WireMock Cloud copy, where each is a stub edit layered onto the same response schemas this instance already serves.

import plaid
from plaid.api import plaid_api
from plaid.model.payment_initiation_recipient_create_request import PaymentInitiationRecipientCreateRequest
from plaid.model.payment_initiation_payment_create_request import PaymentInitiationPaymentCreateRequest
from plaid.model.payment_initiation_payment_get_request import PaymentInitiationPaymentGetRequest
from plaid.model.payment_amount import PaymentAmount
from plaid.model.payment_amount_currency import PaymentAmountCurrency

configuration = plaid.Configuration(
    host="https://81l7q.wiremockapi.cloud",
    # required by the client, ignored by the mock
    api_key={"clientId": "any-value", "secret": "any-value"},
)
client = plaid_api.PlaidApi(plaid.ApiClient(configuration))

recipient = client.payment_initiation_recipient_create(
    PaymentInitiationRecipientCreateRequest(
        name="Wonder Wallet", iban="GB29NWBK60161331926819"
    )
)

payment = client.payment_initiation_payment_create(
    PaymentInitiationPaymentCreateRequest(
        recipient_id=recipient.recipient_id,
        reference="Order-99",
        amount=PaymentAmount(PaymentAmountCurrency("GBP"), value=12.50),
    )
)
print("created:", payment.payment_id, payment.status)

fetched = client.payment_initiation_payment_get(
    PaymentInitiationPaymentGetRequest(payment_id=payment.payment_id)
)
print("fetched:", fetched.status)

Frequently asked questions

Why doesn't the payment body reflect the amount I sent?

Registration and content are separate layers here: the store honors your id and forgets your fields. Read back a payment created for £12.50 and the body reports the fixture's £100 Account Funding entry. Assert on ids and status transitions against this instance; echoed amounts take response templating in your own copy.

What does the consent object include?

The full constraint grammar of a sweeping consent in AUTHORISED status — a validity window, a £100 per-payment ceiling, and a weekly £300 periodic allowance. Enforcement logic that answers "is this execution within limits?" reads every field it needs from one response.

The payment token comes back already expired — intended?

Its expiration timestamp sits years in the past, so any token-freshness check will refuse it. That is itself a workable fixture — the stale-token branch is otherwise awkward to produce on demand — and a mint-and-use flow that needs a live-looking expiry can override the one field in a private copy.

Which template covers the wallet side of money movement?

Held balances paying out, rather than a user authorizing a payment from their own bank, is the Virtual Accounts template. Its wallet store behaves like this template's payment store — ids honored, bodies canonical — so test suites spanning the two rest on the same assertions style.

Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.