Reccurent Payments

What is this?
A two-phase flow where the Merchant first validates and tokenizes a card via a POST /v1/payment-links, then later charges that saved card in the background via POST /v1/payments/merchant-initiated — without direct user interaction.

Actors

User — payer interacting with the merchant’s UI (Phase A only)

Merchant — backend; creates the payment link and later triggers MIT charges

PlexyPay — hosted checkout + payment API; orchestration, 3-DS, webhooks

Bank / ACS — issuer/acquirer side (authorization & 3-D Secure challenge)

When to use

Subscriptions, scheduled billing, usage-based charges.

You want lower checkout friction (card saved once) and no PAN handling in your UI.

Security & Prerequisites

Phase A (validation): card entry happens on PlexyPay Hosted Checkout — Merchant never handles PAN → reduced PCI scope.

3-D Secure: if required by the bank, the user completes the challenge during validation.

Webhooks: expose an HTTPS endpoint to receive final outcomes (validation & MIT charge).

MIT Integration Flow

Reccurent Payments

Actors#

When to use#

Security & Prerequisites#

Actors

When to use

Security & Prerequisites