FAQ

Frequently asked questions about the Shift4 Online Ordering API integration.

Third-Party Availability

What happens if 3rd-party is temporary unavailable?

In case we can't reach a 3rd-party via subscription url, or subscription response is 4xx or 5xx, we send back to POS that their request wasn't processed and a retry must be made by server.

Key Points:

  • If webhook endpoint is unreachable, POS is notified
  • POS must retry the request
  • Ensure webhook endpoints have high availability
  • Implement proper error handling and logging

Status Management

What happens if 3rd-party can't accept the requested status?

In general POS must have always "status" up to date. So if something has been changed on 3rd-party side it must be immediately sent back to POS.

Example Scenario:

If POS has requested to CONFIRM an order but Order has been expired, the 3rd-party should respond as 4xx with a message. We will send this message back to the POS and POS will have a way to do a retry.

Best Practice:

To prevent this, 3rd-party should send an updated order status to POS immediately when status changes occur. For expired orders, send REJECTED status proactively.

Response Requirements:

  • Always respond with appropriate HTTP status codes
  • Include descriptive error messages in 4xx responses
  • Push status updates immediately when state changes
  • Don't rely solely on POS retries

Future Orders

How Future Orders are handled in POS?

Future Orders are placed with status ANTICIPATED and can be viewed by Server. Any action is disabled for server till this order status become a READY_FOR_CONFIRMATION.

Future Order Characteristics:

  • Initial status: ANTICIPATED
  • Read-only in POS until status changes
  • Can be modified by 3rd-party at any time
  • Merchant cannot confirm or reject until status changes
  • Must transition to READY_FOR_CONFIRMATION before POS action

Workflow:

  1. 3rd-party creates order with ANTICIPATED status
  2. Order is visible but locked in POS
  3. 3rd-party can update order details while ANTICIPATED
  4. At scheduled time, 3rd-party updates status to READY_FOR_CONFIRMATION
  5. POS can now confirm or reject the order

Status Transitions:

  • ANTICIPATED → READY_FOR_CONFIRMATION (by 3rd-party)
  • ANTICIPATED → CANCELLED (by customer via 3rd-party)
  • Once READY_FOR_CONFIRMATION, normal order flow applies

Was this page helpful?