AI agents and loyalty: proving membership at checkout

An AI shopping agent can request a loyalty benefit when it can present acceptable evidence of the customer’s eligibility and has permission to use that benefit. The merchant applies its own offer rules, calculates the price and checks the purchase authority before completing checkout.

This matters because member pricing changes the purchase decision. An agent comparing only public prices may miss a benefit its customer already holds. Giving the agent unrestricted access to the customer’s account creates a different problem: it may obtain more information and authority than the shopping task needs.

What must a merchant know to apply a member price?

Start with the offer itself. A discount for an active membership may require evidence of current membership and the relevant programme. A tier-specific benefit additionally requires the tier. A one-use promotion needs a redemption record. These are different conditions and should not be compressed into a generic “member” flag.

The merchant should identify the minimum claims it needs, the issuers or account systems it trusts, the freshness of that evidence and the rules for combining offers. Payment details and a complete purchase history are usually separate decisions, not automatic inputs to membership eligibility.

Two ways an agent can access eligibility evidence

Account linking can let a customer connect the shopping experience to a merchant account. The merchant then uses its own records and the permissions granted for the connection. The Universal Commerce Protocol’s identity-linking specification, version 2026-04-08, explicitly includes loyalty and personalised offers among its use cases.

Credential presentation can let a customer present a claim issued by an organisation that the merchant accepts. W3C’s credential model supplies a structure for such claims; it does not require merchants to honour another programme’s benefits. Commercial acceptance remains an explicit agreement or policy.

Read our account linking and credentials comparison for how to choose between these approaches or combine them.

A worked example: membership changes the eligible price

Consider a hypothetical retailer with a HK$600 item and a 10% active-member discount. Delivery costs HK$30. A customer authorises an agent to buy one item for at most HK$580, including delivery.

If the customer qualifies and the offer applies, the item becomes HK$540 and the total becomes HK$570. The purchase fits the limit. If the membership evidence cannot be accepted, the public-price total is HK$630. The agent must not complete that purchase under the original cap.

The useful output is a priced basket with a clear explanation: accepted membership evidence, applicable offer, final total and permission match. These figures illustrate a merchant policy; they are not AIR performance results or a live partner offer.

Viewing a benefit and spending points need different permissions

Requesting a member price is different from redeeming a balance. If an agent may spend points, the customer should understand the maximum redemption, the programme and what happens if the order is cancelled. A broad permission to find discounts should not silently become permission to exhaust a points balance.

Our suggested design is to separate offer discovery, eligibility presentation and redemption. Let the customer approve the actions needed for the task. If a new redemption would materially change the purchase, ask for fresh approval before committing it.

Handle changes between quotation and purchase

A membership can expire, a promotion can end, and a benefit can be redeemed elsewhere. Decide when each fact is checked and how long a quote remains valid. Recalculate when the basket changes; do not assume that a price found during discovery remains available at checkout.

A one-use benefit also needs protection against parallel orders. The merchant should reserve or consume the benefit in a way that avoids awarding it twice, and release the reservation when the defined failure conditions occur. Identity proof alone cannot manage that order state.

Where AIR contributes

AIR Agent is designed to let users bring relevant credentials into agent interactions, including membership and eligibility. AIR Loyalty is a stable points engine. Teams considering a combined flow should agree the supported evidence, redemption controls and integration availability.

The near-term design question is concrete: can a merchant explain why this customer received this price, and can the customer see what their agent was allowed to do? Start there, then use our merchant KYA checklist to test the whole purchase.

Frequently asked questions

Can an AI agent use a customer’s loyalty membership?

It can when the merchant supports the flow, accepts the eligibility evidence and the customer grants the necessary permission. Programme rules continue to determine which benefits apply.

Does a membership credential guarantee a discount?

No. The merchant decides whether it accepts the issuer and whether the customer, basket and offer meet its rules.

Does account linking support loyalty benefits?

Yes. Linking to a merchant account can make existing membership information available within the permissions granted. This can be suitable for benefits managed by that merchant.

Should an agent need separate permission to spend points?

We recommend distinguishing access to offers from redemption authority. Approval should make the points programme and maximum redemption clear.

What happens if eligibility changes before payment?

The merchant should re-evaluate the relevant evidence and price under its freshness rules. If the new total or terms exceed the customer’s approval, the agent needs a new approval.

About AIR

We build identity, money and loyalty infrastructure for businesses. Explore AIR Agent or discuss your commerce flow with AIR.

Moca Network, the identity network of Animoca Brands.