An assistant that books and pays, on the member’s terms.
A member says what they want, in the app or in the assistant they already use, and it comes back held, booked and paid. Flights, stays, tables, tickets and cars from many suppliers go into one basket and are paid in one checkout, on the card in the wallet. Every step runs under a permission the member gave, within limits they set, and is written to a log they own.
For a bank or a network, that is agentic commerce on the rails you already operate: the card at the front of the purchase, the cardholder’s benefits applied before it, and the data coming back as categories and amounts rather than a name.
Spoken or typed in BLACKBOOK, or asked in ChatGPT or Claude through the connector. The request carries the member’s identity and consent with it.
Found, held and booked from connected supply. Whatever sits under the member’s limit goes through; a stay, or anything above it, stops to ask.
Every action is a timestamped event against the permission it ran under: approved, asked, declined or cancelled. The member can see it, and so can the partner, line by line.
From the words to the receipt.
The same path whether the request starts in the app, in another assistant, or from a standing instruction the member set earlier. Identity and consent resolve first; nothing downstream runs without them.
BLACKBOOK ID confirms who is asking and what they have agreed to share, before anything is searched.
Each category of booking has its own limit and its own card. Under the limit it goes through; over it, the member is asked.
Flights, stays, tables, tickets and cars are called as services, with the member’s programmes applied to the search first.
Many suppliers, one basket, one payment on the card, with points where the member chooses. Each line shows what it earns.
Every step is written with its time, the limit it ran under and the card it went on. It can be undone by voice.
Three ways to see it work.
Recorded from the working app and the bank portal. The first is for banks and networks; the other two show what the member sees, from one booking to a whole trip.
An assistant that buys, on the card.
How a cardholder’s assistant buys from connected supply under one consented identity, within limits the cardholder sets, with every purchase written to one log. One card payment for the basket, each supplier paid, and each line’s supplier and category reaching the bank as data.
Voice to checkout.
A member says what they want and the concierge books it: the usual massage tonight, found from past bookings and checked for availability. A limit for each kind of booking decides what goes through and what stops to ask, and the bank sees a token, a category, an amount, a time and a country, never a name.
Kyoto, planned by voice.
One spoken question becomes a trip for two: flights on the member’s airline programme, a stay at their hotel status, dinner each night and the experiences they asked for, already held. One order paid as two payments, so each traveller pays their half and keeps their own rewards.
Demonstration only. The brands, venues and people shown illustrate how BLACKBOOK works; their appearance does not mean a partnership or endorsement is in place.
On the card, on your rails.
When an assistant buys for a cardholder, the card is at the front of the purchase and the bank is in the data. BLACKBOOK takes one card payment for the basket and pays each supplier, so a trip of many suppliers reaches the issuer as one authorisation with each line’s supplier and category attached. The cardholder’s benefits are applied before the purchase, not claimed after it, and the bank’s portal reports what moved against a holdout.
It is delivered as private label, micro-label or through APIs and an SDK, on the card rails the networks already operate, and we are building it to carry the agent credentials the networks are introducing.
- PaymentOne authorisation for the basket; each supplier settled by BLACKBOOK
- BenefitsApplied before the purchase, from the card’s entitlements
- DataToken, category, amount, time and country; never a name or a card number
- MeasuredLift reported against a holdout, in the bank’s portal
- DeliveredPrivate label, micro-label, or APIs and an SDK in your own app
One trip, one authorisation · what the bank sees
Your supply, reachable where people already ask.
It runs in both directions. A member can ask in ChatGPT or Claude through the BLACKBOOK connector and the request arrives with identity, consent and payment attached. And a partner’s rooms, seats, tables and benefits can be reached by other agents the same way, so they are found and bought where the customer is already asking, rather than only on the partner’s own site. The permission, the limits and the log travel with the request wherever it starts.
- InboundA question in ChatGPT or Claude becomes a held, paid plan in the app
- OutboundYour inventory and benefits, callable by other agents with consent attached
- AttributionServer-side and first-party, so the demand is yours to see
Where a request can start
What is shared, and what never is.
An assistant acting for a member only works if the permission is real and provable. The identity layer resolves what an agent may see before anything is retrieved, so data a member has not shared is never reached, rather than filtered out afterwards.
The member decides what each supplier sees, a switch a line, and can withdraw at any time. Each permission is recorded with the time it was given and is read, not assumed, on every request.
Every category of booking has its own limit and its own card. A stay always asks first. Anything above a limit stops and waits, and the answer is logged with the rest.
Approved, asked, declined or cancelled, each with its time, the limit it ran under and the card it went on. The partner sees the events that concern it; the member sees all of them.
See it run on your card.
A walkthrough of a booking by voice, start to finish, with your programme in the wallet and your portal showing what came back.