DIRECT EMPLOYEE-CARD PAYMENT
One card choice.
One API charge.
Vending FE sends printed card data and product details directly to Boon Backend. The backend authenticates the request, maps the employee, validates balance, and deducts the requested points.
SEQUENCE DIAGRAM
Charge flow running in this demo
No redirect, polling, webhook, or pre-charge account lookup.
- 01Select a drink
Vending FE keeps the selected product ID, name, and Boon price for the demo request.
- 02Choose an employee card
The simulator provides a printed
card_id. It does not expose user ID, balance, or payment credentials. - 03Send the direct charge
POST /api/integration/chargeincludesX-Api-Tokenand a plain JSON body. - 04Deduct points
Boon Backend maps the card, validates balance, records the payment ledger entry, and returns the payment ID and new balance.
ACTUAL API CONTRACT
Plain JSON, protected by an API token
The browser credential is visible because this is a functional demo. A production vending machine must keep its API credential outside public frontend code.
{ "card_id": "0006523856", "boon": 25, "additional_data": { "product_id": "orange-pop", "machine_id": "VM-01" } }
X-Api-Token: demo-api-token must match BOON_API_TOKEN.
Every accepted charge request creates a payment, so clients must avoid accidental retries.
POST /api/integration/refund uses payment_id and the same auth header. Try it in Swagger.
Payment Backend still serves Vending FE and keeps the older QR demo available. The direct employee-card purchase calls Boon Backend through the gateway.