Create a payment operation
Start a pending TPV payment operation for a Harbor Soho POS ticket when the operator uses a terminal-compatible non-manual payment method. The action records the requested amount and selected line allocation plan, but it does not settle the ticket or create the final ticket payment.
In this article
Use this guide when a floor operator sends a ticket payment request to a terminal or integration instead of recording a manual payment.
The operation is only the start of the payment flow. Treat the ticket as unpaid until a later claim or completion action creates the actual ticket payment.
Before you start
- Harbor Demo Group and Harbor Soho are selected.
- The operator can use TPV for the location and access the ticket being charged.
- A current TPV terminal is selected.
- The ticket is not void and still has a pending amount with selectable pending lines.
- At least one active payment method is compatible with the selected terminal and has an execution mode other than manual.
- Cash-like non-manual methods also need an open cash register session for the ticket service session and terminal.
Instructions
- 1.
Open the advanced payment screen
Open the POS ticket payment screen for the Harbor Soho ticket, terminal and staff context. The screen loads the ticket, TPV settings, terminal-scoped payment methods, existing operations and staff labels.
- 2.
Review selected ticket lines
Check the pending lines selected by default. The operator can adjust selected units or enter a smaller amount for a partial charge.
- 3.
Choose a non-manual terminal method
Select a method shown for the current terminal whose execution mode is not manual. Manual methods follow the direct ticket-payment path and do not create this operation.
- 4.
Start the charge
Press Charge. Antylogic creates a pending payment operation with the ticket, payment method, terminal, requested amount and selected item allocation plan in request_payload.allocations.
- 5.
Confirm the pending operation
After creation, the screen clears amount inputs, refreshes the ticket and operation list, and shows the new pending operation while the ticket remains unsettled by this action.
Validations and limits
- The payment screen requires organisation, location, ticketId and location:tpv:use.
- The frontend blocks payment creation for void tickets.
- No current terminal means compatible methods are not exposed for this flow.
- Charge is disabled when no method is selected or the computed amount is zero.
- The backend requires ticket_id, payment_method_id and a positive requested amount after rounding.
- Ticket, method, terminal and supplied staff must belong to the current location.
- request_payload and response_payload must be JSON objects, not arrays.
- Creating the operation does not create ticket_payment rows, ticket_payment_allocation rows or TPV output jobs.
- The current frontend create payload does not send requested_by_staff_id, even though the backend supports that field for direct API callers.
Expected result
A tpv_payment_operation is inserted with pending status, terminal context, requested amount and allocation intent. The ticket remains unpaid until a later payment-operation completion flow creates the actual ticket payment.