Payment Lifecycle

Payment Lifecycle — What Your Users Should See

Every payment moves through a defined lifecycle, and each stage should map to a clear user-facing status in your product:

Method Status	User-Facing Copy	Description
Pending	”Payment scheduled” or “Payment queued”	The payment has been created and is waiting for the next processing window.
Canceled	”Payment canceled”	The payment was canceled before it was processed.
Processing	”Payment in progress”	The payment is actively being processed through the banking system.
Sent	”Payment sent to your creditor”	Funds have been initiated and sent to the creditor.
Delivered	”Payment delivered”	The destination rail reports that the payment was delivered.
Posted	”Payment complete”	The creditor has confirmed the payment has been applied to the account.
Cashed	”Payment cashed”	A check payment was cashed by the recipient.
Failed	”Payment couldn’t be processed”	An error occurred — see failure details.
Reversal Required	”Action required”	The payment requires a reversal before processing can finish.
Reversal Processing	”Reversal in progress”	A reversal has been approved and is being processed.
Partial Reversal Processing	”Partial refund in progress”	The creditor returned part of a delivered payment, and a refund of the returned amount is in progress.
Reversed	”Payment returned”	A previously sent payment was returned.
Partially Reversed	”Partial refund complete”	The amount the creditor returned has been refunded to the payment’s reversal account.
Settled	”Payment settled”	Reversal processing ended with the payment settled rather than reversed.

Design your product to show clear status transitions as webhook events arrive. Users should feel confident that their money is moving and that the system is working, ambiguity about payment status is one of the fastest ways to erode trust.

Handling Reversals and Failures

Payments can fail or be reversed, and your product should be able to handle these scenarios gracefully: Failed Payments Failed payments can occur at various stages due to insufficient funds in the funding account, invalid or closed account details, or creditor rejection. When a payment fails, Method emits a webhook event with the failure details. Your product should notify the user clearly, explain what happened in plain language, and provide a path to retry if applicable. Reversed Payments Reversals occur when a payment that was already sent is returned. For example, this can happen if the funding account has insufficient funds after the payment is initiated, or if the creditor returns the payment. Reversals are tracked as separate objects with their own lifecycle and webhook events. Your product should notify the user when a reversal occurs, explain what happened, and update any progress displays associated with the original payment. In some cases, a creditor may accept a payment and later return only part of it. Method automatically refunds the returned amount and the payment transitions through partial_reversal_processing to partially_reversed. To determine how much was returned, retrieve the reversal using the payment’s reversal_id. Fees are not refunded for partial reversals.

Settlement Timing

Settlement and posting timing varies by creditor and payment rail. Do not make hard assumptions about when a payment will post.

Getting Started

Entities

Identity Verification

Connect

Accounts

Updates

Payments

Additional Products

Use Cases: Commerce

Use Cases: Lending

Use Cases: PFM