Guide

Look up a customer at the till and charge to their profile

A common point-of-sale scenario: the customer walks up, you find their profile in Trybe, see what memberships they hold and what payment methods they've stored, then settle the bar tab or treatment charge against one of those methods so the receipt lives in Trybe instead of an out-of-system card reader.

Three building blocks: find the customer, read their context (memberships + payment methods), and settle through Trybe (basket → order → payment against a stored method).

1. Find the customer

Three lookup paths, depending on how the till identifies the customer.

By loyalty barcode (most POS hardware)

If the till has a barcode scanner and you've issued the customer a loyalty card or app barcode, scan it and look the customer up:

curl "https://api.playground.try.be/customers/barcode-search/$BARCODE" \
  -H "Authorization: Bearer $TRYBE_API_KEY" \
  -H "Accept: application/json"

Returns the Customer if a barcode matches, 404 otherwise. See getCustomerByBarcode.

By name, email, or phone

For tills with a search box (or a "find customer" modal):

curl "https://api.playground.try.be/customers/customers?query=$QUERY&site_id=$SITE_ID" \
  -H "Authorization: Bearer $TRYBE_API_KEY"

query matches against name, email, and phone. Hold the result in state for the rest of the interaction. See listCustomers.

By customer ID (already known)

When the customer is already loaded from a parallel system (room booking, appointment record, etc.) and you have their UUID:

curl "https://api.playground.try.be/customers/customers/$CUSTOMER_ID" \
  -H "Authorization: Bearer $TRYBE_API_KEY"

getCustomer.

2. Pull their POS-relevant context

Two parallel reads give you everything the till needs to show on the customer summary panel: memberships and payment methods.

Memberships

Show what the customer is currently subscribed to — staff use this to confirm member-only pricing, complimentary treatments, or package allowances.

curl "https://api.playground.try.be/customers/memberships?customer_id=$CUSTOMER_ID" \
  -H "Authorization: Bearer $TRYBE_API_KEY"

Filter the returned list by status: active (or confirmed, depending on your billing model) to ignore cancelled or expired records. See listMemberships.

Saved payment methods

Show every card or direct-debit mandate the customer has on file, so the till can offer "charge to this card" as a one-tap option:

curl "https://api.playground.try.be/customers/payment-methods?customer_id=$CUSTOMER_ID" \
  -H "Authorization: Bearer $TRYBE_API_KEY"

A PaymentMethod has a type of card or direct_debit, a status (revoked methods can't be charged), and the last-four / card-brand metadata to render a recognisable label. See listPaymentMethods.

3. Take the order through a basket

The actual sale follows the standard basket + checkout flow, with one addition: attach the customer to the basket so the order is linked to their profile from the start.

Open a basket

curl -X POST https://api.playground.try.be/shop/basket \
  -H "Authorization: Bearer $TRYBE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "site_id": "'"$SITE_ID"'", "customer_id": "'"$CUSTOMER_ID"'" }'

Passing customer_id on creation saves a separate actionSetBasketCustomer call. See createBasket.

Add items

Add each line — treatments, products, drinks, retail — via createBasketItem. The basket totals (sub-total, tax, member-discounted lines) recalculate on every change.

Pre-submit dry-run

Before you commit, run actionPreSubmitBasket to surface any blockers — out-of-stock items, lapsed memberships, missing terms acceptance. Catching these before the customer swipes their card keeps the queue moving.

Submit

actionSubmitBasket locks the basket and creates the underlying Order. From here on, payment is against the order, not the basket.

4. Charge against the stored payment method

With the order created, charge the chosen saved payment method. This is what "settle in Trybe" actually means — the order's payment record is created against the customer's existing method, no external card reader involved.

curl -X POST "https://api.playground.try.be/shop/orders/$ORDER_ID/payments" \
  -H "Authorization: Bearer $TRYBE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 12500,
    "capture_method": "automatic",
    "processor_data": { "payment_method_id": "'"$PAYMENT_METHOD_ID"'" }
  }'
  • amount is in the lowest denomination of the order's currency (pennies for GBP, cents for USD). Pass the order's outstanding balance to settle in full.
  • capture_method: automatic charges immediately. Use on_demand for "save for later" flows where you don't want to take the money yet.
  • processor_data.payment_method_id points at the saved method selected in the previous step.

See createOrderPayment.

Trybe charges the stored method through its payment processor and writes a Payment record against the order. The order's status transitions to paid once the charge settles. Subscribers to the payment.complete webhook get notified.

If the charge fails

The order stays unsettled and the till should offer an alternate method — another saved card, a fresh card swipe, cash, or split- across-methods. Trybe doesn't auto-retry on the same payment method; that decision lives in the till's UX.

End-to-end at a glance

                ┌──────────────────────┐
   Scan         │  getCustomerByBarcode│
   barcode ──▶  │  (or listCustomers)  │
                └────────┬─────────────┘
                         ▼
                ┌──────────────────────┐
                │ listMemberships      │
                │ listPaymentMethods   │
                └────────┬─────────────┘
                         ▼
                ┌──────────────────────┐
                │  createBasket        │
                │  createBasketItem ×N │
                │  actionPreSubmit     │
                │  actionSubmitBasket  │
                └────────┬─────────────┘
                         ▼
                ┌──────────────────────┐
                │  createOrderPayment  │
                │  (processor_data:    │
                │   payment_method_id) │
                └────────┬─────────────┘
                         ▼
                payment.complete webhook
                order.status → paid

When the customer doesn't have a saved card

If listPaymentMethods comes back empty, three options at the till:

  • Capture a card live — call createOrderPayment with details_source: terminal and the in-store card reader handles the swipe. The captured method can be persisted onto the customer profile with processor_data.save_payment_method: true for next time.
  • Pay-by-link — send the customer a payment link (details_source: pay_by_link) and settle the order asynchronously when they tap through. Useful for room-charge flows where the bill is finalised later.
  • Cash / external reader — record the payment with a details_source that matches your reconciliation flow. Trybe treats the order as settled but doesn't take the money itself.

See createOrderPayment for the full set of details_source values your tenant supports.