Skip to content
Last updated

Understanding Invoices

It is crucial that an interface handle invoice numbers correctly because the invoice number is a unique identifier for a transaction on a per-batch basis in Shift4's Gateway.

The invoice number is used for any subsequent requests relating to the initial request, such as converting an authorization to a sale, incremental authorizations, or a void. For subsequent requests, the invoice number from the initial request is used to link to the transaction.

Refunds and credits are not considered subsequent requests, so these transactions require a new invoice number. If the same invoice number is used for a Refund as was used for the sale, the consumer could end up with a net credit. For example, if invoice 1225151234 is used for a $100 sale and later that same day, a refund is processed for $25 using the same invoice number, the customer will receive a $25 net credit instead of being charged a net of $75 because the invoice was overwritten before the batch was processed by the merchant.

Shift4 requires that your interface be designed to never reuse an invoice number once a payment flow is complete within an individual batch.

Incremental Authorizations

Incremental authorizations are commonly used in lodging where the final amount for the guest’s bill is unknown. They may also be used in F&B interfaces ("bar mode"). While an initial authorization will be made and an invoice number will be assigned to the guest’s bill (i.e., the folio), additional transactions may also be needed, such as if the guest extends their stay or purchases incidentals. These additional transactions, or incremental authorizations, are added to the same invoice number.

At Shift4, incremental authorizations share the same invoice number. When the guest checks out, the sale is captured for the final amount, including the initial authorization and all approved incremental authorizations.

Sometimes, incremental authorizations are declined. When this occurs, Shift4's Gateway automatically rolls the transaction back to the last valid authorization on file.

Lodging

Use Case: Processing an Incremental Authorization (Lodging)

Actors: Interface, Shift4, Clerk

Preconditions: The merchant has an approved initial transaction for a guest’s folio.

Main Flow: This flow illustrates an incremental authorization request used to increase the amount on an existing authorization.
  1. The clerk initiates an authorization transaction through the interface.
  2. The interface sends an Authorization request and the card token from the initial transaction to the UTG with an amount greater than the existing authorization.
  3. The UTG sends the card token and transaction request to Shift4's Gateway for processing.
  4. Shift4's Gateway returns a resultant card token and approval result to the UTG.
Alternate Flow: This flow illustrates a referral response. (Main Flow; Step 4.)
  1. The clerk chooses to continue the transaction after receiving an ‘R’ response. This response includes the data provided in the merchant.cardTypes array.
  2. The clerk calls the phone number provided and follows the instructions.
  3. The Voice Authorization Center approves the transaction and a voice authorization code is provided.
  4. The interface sends a Manual Authorization request to add the incremental authorization to the invoice in Shift4's Gateway.

F&B

Shift4 is certified with only a subset of processors for incremental authorizations in F&B. If your interface will use this functionality, please check with your CSD regarding which processor(s) you expect merchants using your interface will use in production. Attempting to use incremental authorization flows on a processor which Shift4 has not certified those flows with, may result in trouble with tolerance guarantees, downgrades, and ghost authorizations.

Previous page
Next page