Skip to main content
A payment records money received against one or more invoices, by processor, credit note or gift certificate. This area has 15 endpoints: create, read, update and delete payments, list them by invoice or order, and manage their notes and files. Every SDK supports all of them.
Creating a payment can charge a card. If a payment_applied entry names a processor that holds a saved card token, the card is charged.

At a glance

Before you call

Register your API credentials once when your app starts, as shown in Authentication. Every SDK sample on these pages then gets its client in one line. With cURL, send the access token in an Authorization header: Authorization: Bearer $ACCESS_TOKEN.

Things to know

  • Write bodies go under a payment key. Creating a payment accepts only id, date, origin, payment_note, note, invoices, payment_applied, credit_applied, gift_certificates and custom_attributes; any other key returns 400.
  • A payment’s invoices name each invoice by its inv_ uuid. Creating a payment takes the invoice’s id, such as INV-0001, but reads return the inv_ uuid in that field.
  • Listings page by cursor. Records are under data. Pass pagination.next_cursor back as cursor while pagination.has_more is true.
  • Deleting a note takes its uuid, not its id. Reads take the note’s id; the delete takes the hex part of that id as a dashed uuid.
  • Reading a payment through an invoice does not check that the payment belongs to it. Any payment is returned under any invoice that exists.
  • Note text goes in a form field. Creating a note sends a multipart form with the text as note and any attachment as file.