The most important moment in a grocery order is not always the search. It is the moment before money moves. Until then, an assistant can gather the things you asked for, compare what is available and bring the next step into view. After that moment, an intention has become a purchase. A person should be able to see that boundary before crossing it.

Surf is an Android assistant that can act across your apps, a cloud browser and connected services. That makes the boundary especially important. Asking for help with dinner should not quietly become permission for an unknown merchant to charge an unknown total. Surf asks before anything that spends money, using a pay card that you tap to approve.

An instruction is not a blank cheque

“Order milk and eggs” sounds simple because a person can fill in the gaps from experience. Which size? How many eggs? Is the usual brand available? Has the delivery charge changed? Some answers might be clear from the task; others need a decision. The sentence explains what the person wants. It cannot settle every detail of a checkout that has not happened yet.

That is why the approval point belongs near the actual payment. Approving a general idea at the start and approving a specific amount at the end are different decisions. The first gives Surf a direction. The second gives the person a chance to check what that direction produced. The interface should make that distinction obvious, without asking someone to interpret a long conversation.

A request starts the task. Approval authorises the payment.
pay boundary article diagramPermission is the boundary.Prepare the orderYou review & approveThen payNo approval → no paymentThe total, merchant and items belong in the review.

Make the decision readable

A useful pay card brings the things that affect the decision together: the merchant, the items and the total. The person should not have to reconstruct a basket from scattered messages. It should be possible to compare the result with the original request and spot the detail that does not fit. Is this the right shop? Are these the right items? Is this the amount I am willing to pay?

The card also gives the task a visible stopping point. Surf can be useful before that point without pretending that a purchase has happened. It can help prepare the order and surface the choice. The next step is waiting for the person. Language matters here: a basket awaiting approval is not an order confirmation, and a request to approve is not a receipt.

No approval means no payment

This rule is deliberately easy to explain. If a task spends money, Surf must ask. The user can review the card and approve, or leave the payment unapproved. The convenience of an assistant does not make this choice unnecessary. In fact, convenience makes the choice more important, because a person may not have watched every step that led to it.

Consider a dinner request with a preferred time and a budget. Finding an option is useful work. Reaching a checkout is progress. Neither tells us that the person accepts the final offer. A delivery fee or a different available item may change the answer. The pay card returns the decision to the person at the moment when the concrete details are available.

Approval and secure input do different jobs

Payment approval is a decision about an action. A password or OTP is a secret used to authenticate. These should not be treated as interchangeable pieces of chat. Surf uses secure input for passwords and OTPs, and those values are never sent to the model. The person should not need to put a secret into an ordinary request to help the assistant continue.

Keeping these concepts separate helps explain the experience. Surf can ask whether a payment is authorised without asking the user to narrate a password. Authentication may still require the person to take part. That involvement is a meaningful boundary, not an inconvenience the assistant should try to hide. An incomplete task is better than a misleading claim that a protected step was completed.

A clear pause is part of good assistance

A pause can feel awkward if the interface gives no reason for it. A clear pause feels different: the person sees what is waiting, why their decision is needed and what the choice means. For a payment, the reason is straightforward. This step uses your money, so you make the call. The product should say that plainly rather than wrapping the moment in urgency.

This also shapes how we show Surf on the website. The editable phone is an illustrative preview. It does not open a shopping app, access an account or take a payment. Trying the request demonstrates the shape of a conversation, not the completion of a real order. That distinction should remain visible even when the interaction feels smooth and immediate.

Useful, with a boundary you can remember

An assistant earns a place in everyday life by making work easier to follow, as well as easier to start. The approval rule is one part of that. It gives people a short answer to an important question: can Surf spend without checking with me? No. The pay card is where the person reviews the actual purchase and chooses whether to proceed.

This is a draft product note, not a promise about every merchant or checkout. Availability and the steps needed to finish a task depend on the service involved. The principle stays simple across those differences: Surf can help you reach a decision, but a task that spends money waits for your approval.

Draft for review. Examples are illustrative; no metrics, customer quotations or research results are claimed.

Back to the notebook ↗