Void a payment by its ID. A voided payment is retained rather than deleted — its record still resolves and it keeps appearing in the list and show endpoints with status VOIDED. The response returns the payment in its post-void state.

This one endpoint voids both kinds of payment; it dispatches on payment_type: • INVOICE — reverses the money applied to the invoice, recomputes the invoice's payment status, and cancels both the credits this payment generated from an overpayment and the credits applied toward it. Requires the invoices_permissions_receive_payment permission. A payment on an invoice the authenticated user cannot view under their team restrictions returns 403. • PURCHASE — reverses the money applied to the purchase, recomputes the purchase's payment status and updates the payment's updated_datetime. Requires the purchases_permissions_make_payments permission. A payment on a purchase the authenticated user cannot view under their team restrictions returns 403.

Voiding an already-voided payment returns 400. If the company is connected to QuickBooks Online, the void is queued to sync there (a 200 is not confirmation it reached QuickBooks Online — poll QuickBooks Online to observe the result); an invoice payment is also pushed to LeafLink when that integration is configured for the customer. The change is eventually consistent — it can take up to 1 second to reflect in the list and show endpoints.

{
  "data": {
    "company": {
      "id": "3f128a34-cc59-4b49-8883-23bf10e59c6c",
      "name": "Retailer 1"
    }
  }
}