Initiates a card-present sale (auth + capture) on a paired terminal. The initial synchronous response will often have success = false and a message like terminalservice.waiting while the customer is interacting with the device. Poll GET /terminal/{registerId}/status/{transactionId} (or listen for webhooks, if configured) until the transaction reaches an approved or declined state.
Workflow:
- POST this endpoint with
total,register, optionalinvoiceId, andmetafields. - Terminal wakes and prompts customer to insert, tap, or swipe.
- (Optional) Signature / additional prompts may fire based on card brand, amount, or merchant configuration.
- Status endpoint returns approved/declined details; final transaction object will have
success = truewhen approved.
Key Fields:
total: Decimal amount in dollars; must be >= 0.01; negative values are not allowed.meta.lineItems: Array of { price, quantity, item, details } used for receipts & reporting (schema not previously documented).printReceipt: One of Merchant|Customer|Both|No; defaults to Both. If the hardware cannot print, receipt is silently skipped.paymentType: Currently most terminals default toCredit;Debit,Gift, etc. depend on device/gateway support.tokenize: If card-present tokenization feature is enabled and true, Stax will attempt to create a reusable payment method after settlement (see Settlement Tokenization).invoiceId: Link the sale to an existing invoice for reporting and partial payments.
Business Rules:
- Pre-authorizations: For variable final amounts, pass
pre_auth = true(if supported); capture later via standard transaction endpoints. - Idempotency: Provide a unique
idempotency_idinmetaif you need safe retries; duplicate will return original transaction. - Tips: If supported by device configuration, tip prompts may occur automatically (not defined in schema here).
- Custom Fees: Card-present sales cannot use
meta.customFee.
Errors & States:
- 422 validation errors before reaching a gateway (e.g. missing register).
- 400 gateway errors after processing attempt (e.g. decline).
- Cancellation: Customer or merchant cancels;
cancelled = true. - Offline Approval: Terminals may approve offline; final capture occurs at batch close.
Security: Requires ApiKeyAuth or EphemeralAuth. PartnerApiKey may be required for advanced features (e.g. settlement tokenization enablement).
PCI: Raw PAN data never passes through your application; terminal handles encryption.
Polling Recommendation: 1–2s interval, max 30 attempts, then surface a timeout error and instruct merchant to check device.
Receipts: Email/SMS receipts can be triggered using transaction receipt endpoints after approval.
Wake the terminal with a request for the user to insert the card. This call is SYNCHRONOUS, meaning the network call will stay open until the transaction is finished. The call will time out after only 60 seconds if the transaction is not completed, and you will not receive the response, unless you poll the GET transactions resource.
For this reason, we recommend using the charge/queue resource.
Timeout Behavior
When a timeout occurs during a transaction because it is not completed on time, Stax creates a scheduled task to begin querying the terminal for the status of the transaction. The schedule waits 3 minutes after the timeout and queries the terminal for the transaction status every minute for the next hour. Once Stax receives a response from the terminal, the transaction will display in Stax. Until a response from the terminal is received or the schedule finishes.
Note: THE TRANSACTION WILL NOT DISPLAY IN Stax.
Synchronous vs Asynchronous
Use when you want the transaction data immediately and are ok with a slower HTTP response. The call stays open until completion but times out after 60 seconds.
Recommended approach - Get a quick HTTP response without waiting for transaction completion. Transaction data is available later through polling or webhooks.
Both /terminal/charge and /terminal/charge/queue are valid solutions depending on your use case. For most use cases, we recommend charge/queue.
