Create a house account transaction
Records a charge or payment against a house account and moves its balance by the amount. Supply an idempotency key so a retry returns the transaction already recorded rather than moving the balance twice.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
Body
Records a charge or payment against a house account, either a sale tendered to the account or an adjustment such as a customer settling what they owe.
Money the transaction moved. A negative amount is a charge, which grows what the customer owes; a positive amount is a payment or refund, which reduces it.
^-?[0-9]+(\.[0-9]+)?$"199.99"
Key supplied when the transaction was created, unique within the banner. Sending the same key again returns the transaction already recorded rather than charging the account twice.
What produced the transaction: a sale or refund rung up at a register, or an adjustment made in the back office.
manual_adjustment, order_payment Note to write alongside the transaction, such as why the adjustment was made.
ID of the employee who took the transaction. Only a register sends one, and it is required there; a back-office session records the signed-in user and an API key records itself.
^[0-9]+$Your own key/value pairs, stored with the transaction and returned unchanged. Vori never interprets them. Up to 50 keys; key names up to 40 characters of letters, numbers, underscores, and hyphens; values up to 500 characters. Keys beginning with "vori" are reserved. Do not put personal or sensitive information here — these values flow into reporting and data exports.
ID of the checkout this settles, from the transactions resource. Required on an order_payment and rejected on a manual_adjustment.
ID of the store the transaction belongs to. Required, except from a register, which posts against the store it is installed in.
^[0-9]+$Response
House account transaction created successfully.
One charge or payment on a house account. The ledger is append-only, so a transaction is never edited or removed once recorded; a correction is another transaction.
Unique identifier for the record.
Money the transaction moved. A negative amount is a charge, which grows what the customer owes; a positive amount is a payment or refund, which reduces it.
^-?[0-9]+(\.[0-9]+)?$"199.99"
ID of the API credential that recorded the transaction. Null when a person did.
When the record was created.
Note written alongside the transaction, such as why an adjustment was made.
When the transaction took effect. A sale carries the time it was completed at the register, which can be earlier than when it reached the ledger.
ID of the employee who took the transaction at a register, or null when it was made in the back office.
^[0-9]+$The account balance after this transaction. A negative balance is what the customer owes the store. A positive balance is credit the customer can spend.
^-?[0-9]+(\.[0-9]+)?$"199.99"
Key supplied when the transaction was created, unique within the banner. Sending the same key again returns the transaction already recorded rather than charging the account twice.
Your own key/value pairs, exactly as supplied when the transaction was recorded.
ID of the checkout this settled, from the transactions resource. Null when the ledger entry is not tied to a checkout.
ID of the store where the transaction took place.
^[0-9]+$What produced the transaction: a sale or refund rung up at a register, or an adjustment made in the back office.
manual_adjustment, order_payment When the record was last changed.
ID of the back-office user who made the adjustment. Null for a transaction taken at a register.
^[0-9]+$