Refunds, Cancels, and Voids

Refunds, cancels, and voids handle different moments in the payment lifecycle. Use the operation that matches the current state of the payment session.

Operation	Use it when	API reference
Cancel	The session was created, but the customer has not entered payment information.	`POST /payments/v1/payment_session/{business_id}/cancel`
Void	A manual capture authorization exists and you want to release the hold without capturing.	`POST /payments/v1/payment_session/{business_id}/void`
Refund	Funds were captured and you need to return some or all of the payment.	`POST /payments/v1/refund`

Cancel a pending session

Cancel a payment session when checkout should no longer continue and the customer has not entered payment details yet. After cancellation, keep the order unpaid or let the customer choose another payment method.

Void an authorization

Void a session when you used Manual/Delayed Capture and no longer want to capture the authorization. Voiding releases the hold instead of settling funds.

Refund a captured payment

Refund a payment after funds are captured. Use refunds for post-payment returns, order adjustments, or customer support cases where funds need to move back to the customer.

For itemized orders, use the payment session details and webhook payloads to reconcile which items or amounts remain refundable.

Choosing the right operation

Payment state	Operation
Customer has not completed checkout	Cancel
Authorization was created, but should not be captured	Void
Payment was captured	Refund

If you are not sure which state a payment is in, retrieve the payment session first: GET /payments/v1/payment_session/{business_id}.