Scheduled and recurring payments

Charge a saved payment method once at a future date, or on a repeating cadence, without a person having to trigger every individual charge.

Flat or itemized

Send either a single amount (a tax-free charge) or lineItems with a taxRateId / taxRatePercent. Each run then creates an invoice with those lines and tax and charges its total, so the customer gets an itemized receipt and the merchant's accounting sync sees real lines. A productId on a line must be one of the merchant's products.

If a charge fails

PayMidWare retries automatically — up to 3 consecutive failures, spaced 4 hours apart — before marking the schedule Failed and pausing it on its own. A failed schedule isn't dead: fix the underlying payment method, then resume it manually.

Managing a schedule

/Merchants → your merchant → Scheduled payments, or start one from a specific customer's page (Customers → a customer → Schedule a payment)

Endpoint	Purpose
POST /api/merchant-accounts/{ref}/scheduled-payments	Create a schedule against a saved payment method.
GET .../scheduled-payments	List a merchant's schedules (also GET .../scheduled-payments/{id} for one).
POST .../scheduled-payments/{id}/pause	Pause an active schedule.
POST .../scheduled-payments/{id}/resume	Resume a paused or failed schedule.
POST .../scheduled-payments/{id}/cancel	Cancel a schedule for good.
POST .../scheduled-payments/{id}/run-now	Trigger an out-of-band charge attempt immediately — handy for testing.

The API has no endpoint to edit an existing schedule — cancel it and create a new one. In the Portal a merchant can edit a schedule's details while it is paused or failed.

Ask the customer to approve a schedule

When you don't have a saved payment method yet, create a schedule request: the customer gets a link, reviews the amount and cadence, enters their payment method, and approves — and only then does a schedule exist. A request can be tied to an invoice or stand on its own; either can be flat or itemized.

A schedule, and a schedule request, can carry billToAddress and shipToAddress (the same line1, line2, city, state, postalCode, country shape as an invoice's; both optional; over-long fields are a 400). Send them on create schedule, either schedule-request call, and read them back in the summaries. They are copied onto every invoice and receipt the schedule produces, the customer approving a request sees them, and a blank bill-to means the customer's billing address. A request tied to an invoice with none sent takes that invoice's addresses.

Endpoint	Purpose
POST /api/merchant-accounts/{ref}/invoices/{invoiceNumber}/schedule-requests	Ask the invoice's customer to approve a schedule against it.
POST /api/merchant-accounts/{ref}/customers/{customerId}/schedule-requests	The same with no invoice; you name the gateway.
GET .../schedule-requests	List requests (also GET .../schedule-requests/{id}).
POST .../schedule-requests/{id}/cancel	Withdraw a request the customer hasn't approved.