Starts a refund of an eligible employee or contractor payment, returning the funds to the employer. If the refund cannot be sent before an employer refund attempt is created, start the refund again after resolving the unmet precondition. If an employer refund attempt is created and then fails, use POST /payments/{payment}/retry with an active employer bank account different from the account used by the failed refund.
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
Refunds are possible for failed credit payments associated with funded payrolls.
A refund indicates that a payment will be completed off-platform by the company, and they will now bear the responsibility for paying that employee, usually by a check. The net pay funds collected by Check for this employee will be returned to the company within 1-2 banking days. Additionally, the corresponding parent payroll_item or contractor_payment will have its payment_method set to MANUAL.
We recommend relying on the can_refund field on the Payment object to guide whether a refund is possible.
Failed refunds
If Check sent an employer refund and that refund failed, the payment reads refund_failed with can_refund set to false and cannot be refunded again. Retry it with Retry a payment or refund and an active employer bank account different from the one the failed refund used. Calling this endpoint on that payment returns a 400 with type payment_ineligible_for_refund and the message This refund failed and must be retried using the retry action.
Status Changes from RefundsRefunding a failed payroll item or contractor payment sets
payment_methodtoMANUALand marks the item status aspaid. If all items in the payroll are now complete, the parent payroll status will transition topaid. Status-change webhooks will fire for the item and, if applicable, the payroll, so ensure your automations and notifications handleMANUALpaid items appropriately.