This article answers the most common questions partners and developers ask when integrating with the Como API. It covers assets and gifts, points and payment, core API calls, promotions, and general configuration.

Assets, Gifts & Rewards

Can the Como API show only redeemable gifts before the checkout screen?

Yes. Businesses can configure the API to indicate whether an asset is redeemable, making it easy to filter out non-redeemable assets. When enabled, the API response includes a redeemability flag on each asset (provided it meets the conditions set in the asset's configuration).

To use this, send a getMemberDetails request with:

https://api.prod.bcomo.com/api/v4/getMemberDetails?returnAssets=active&expand=assets.redeemable

The request must include purchase details so Como can validate redeemable conditions against the items in the cart. On a successful call, each asset returns a redeemability flag (true / false).

Do you recommend showing non-redeemable gifts to customers?

Showing non-redeemable gifts (visible but grayed out and unclickable) can help upsell purchases. For example, a customer who sees a 50% discount on an item may be encouraged to add it to the cart.

If you implement this, we recommend:

• Displaying the customer's available benefits at the beginning of the purchase rather than at checkout, to reduce cart abandonment.
• Including the reward description (available on Como) so the customer understands what they need to purchase to earn the benefit.

What is an "in-progress inactive" gift?

It means the gift is currently being redeemed elsewhere in an open/active order.

Can a customer see how much of a digital punch card has been used through a POS?

Yes. Punch card status is available in the response of the gifts API call. We highly recommend kiosks display punch-card status. See the getGifts call documentation for details.

Why should we fetch inactive assets?

Fetching inactive assets gives members better visibility. For example, a member searching for a gift that has expired can see it grayed out and unclickable instead of being confused about why it's missing. This is recommended but not mandatory.

How many asset statuses are there?

There are three:

1. Fully inactive — non-redeemable under any circumstances (expired, used).
2. Active but not applicable to anything in the current basket.
3. Active and applicable to the current basket.

These are distinguished through the getMemberDetails call response, which returns each asset's status and redeemability. See Swagger for examples.

How does item selection work when enabled in the gift configuration, and how does it function on the POS?

When Item Selection is configured and activated on a gift, the getMemberDetails responses include an itemsSelection object nested inside the relevant asset. This object tells the POS exactly which items the customer must choose to satisfy the gift and which item(s) receive the discount, so you can drive the selection flow directly from the response.

Inside itemsSelection, each entry in discounts[] contains a set of basketRequirements[]. Each requirement includes:

• text — a display label to show the customer (e.g., "Choose a Burger").
• type — how the items are identified: itemCodes or itemsGroup.
• ids — the eligible item identifiers (SKU/PLU codes or group IDs).
• conditions.quantity — the minimum (and, when configured, maximum) quantity required.
• discountedItem — true if the item receives the discount, false if it is a prerequisite the customer must add to qualify.

The discounts[] entry also carries a text label for the overall rule (e.g., "Choose meal") and, when usage limits are configured, maxUsagePerPurchase.

On the POS, the flow is:

1. Read itemsSelection from the member's asset and present the required choices to the customer using the text labels and ids.
2. Add the selected eligible items to the basket, respecting the quantity conditions and maxUsagePerPurchase.
3. Send getBenefits with the updated basket to calculate the actual discount, then submitPurchase to apply and redeem the gift.

If a member attaches a gift to an online transaction but doesn't complete it, is the gift still attached to that transaction (respecting the redeem lock) even if the member has left the app?

Yes. When a gift is sent in a getBenefits call it is locked to that open transaction to prevent the same gift from being fraudulently redeemed elsewhere before it is burned by submitPurchase. This lock is tied to the transaction, not to whether the member is still active in the app — so if the member abandons the order, the gift remains locked/attached to that open transaction.

While the gift is locked, any parallel attempt to redeem it from another source returns error 4005510 ("Asset is locked for redemption. Parallel request was received from another source"). The lock is released when the transaction is resolved — either it is completed with submitPurchase, or it is cancelled with voidPurchase.

Best practice: when a member abandons an online order, send voidPurchase to void the open transaction and release the gift, so the member can use it again in a future purchase. If a Payment call was already sent, also send cancelPayment.

Points, Credit & Payment

Can customers use points and rewards to pay the entire balance (including taxes)?

Yes. To let customers cover the entire balance with points or rewards, the integrator (POS/Ordering/etc.) must support Credit/Points as Tender (a means of payment).

Does Como support paying with points as a discount as well as a form of tender?

Como supports both, but the integrator must handle this as a business-level configuration because it depends on the loyalty model:

• Points from a wallet top-up should be treated as a form of tender by the POS.
• Points accumulated from past purchases should be applied as a discount.

This matters for tax and sales reporting. With accumulation, in countries where tax is calculated after the subtotal (e.g., the USA), tax should be calculated after the discount is applied, because tax was already paid when the points were originally accumulated. With wallet top-ups and credits, the value is considered tender and was not taxed at the original purchase, so tax should be applied. For more detail, see our knowledge base on POS tax configuration.

We receive pointsBalance and creditBalance in getMemberDetails — how do we use them?

Both points and credit can be used as tender; the usedByPayment property determines this. Typically, points are used for the point shop and credit for payment, but not always.

You can display credit on the relevant web view, but you must take its monetary value and divide it by 100 before displaying, because Como uses the smallest currency unit in all API calls. If a conversion rate applies, Como handles the calculation and sends it to you ready as the monetary property.

What does the "ps" at the beginning of a key indicate?

When a member buys a gift from the point shop, the benefit key is returned with a ps prefix. This tells the Como system to deduct the points used and return the relevant asset for the request.

Can we show how many points will be accumulated before the purchase is completed?

No. Como calculates points accumulation according to the customer's configuration after the purchase. Customers can see their benefit status only after purchase completion.

Can we show points earned on an order confirmation page or email?

Yes. The business can include this in the custom message Como shows the user post-purchase — points earned, updated balance, or both.

Core API Calls & Integration Flow

Where can I find API structures and examples?

All information on APIs — structure, examples, uses, and more — is available in the Como developer portal.

Which API call checks if a user already exists?

The getMemberDetails call returns member details if the member exists in the Como database. If they don't, the call returns "Customer Not Found", and the flow should proceed with a registration call.

Why does getMemberDetails include a purchase object? Is it only relevant after a purchase?

The getMemberDetails response returns all assets for the member. Because some assets are cart-dependent, the purchase object is required to determine which assets are redeemable. For example, a free-coffee asset returns as non-redeemable if coffee is not in the cart, but as redeemable if it is.

What are the unique identifiers used across all partners?

The business chooses its unique identifier type — either email or phone number. Our POS partners are expected to support both.

What is a LineID and why is it needed?

A LineID is the unique identifier of a row within the cart. Como uses it to allocate discounts appropriately.

Do we need to send specific values in the orderType field of getMemberDetails?

No. You can use your own format. Como uses these values to determine whether order-type-related rewards apply and for post-transaction automations.

What is the x-branch-id header used for, and what value should it contain?

When ordering from a specific location, the branch ID identifies which branch the order is from. Como needs this to apply location-based promotions, location-based reporting, and more. There is no required format — send any value that accurately represents the branch identity.

If there's no discount for the user, do we still need submitPurchase? Do we need a Payment call?

submitPurchase should be sent every time a purchase is made — POS, online, or kiosk — regardless of whether discounts were applied. This lets Como gather customer data, tailor future benefits, and handle points accumulation.

A Payment call is only required if the customer used points/credit as tender or discount. If points/credit were not used, it is not required. See Payment flows by Como response for the full flow.

What happens if a customer leaves the cart mid-order? Which call notifies Como?

• If the member didn't complete the transaction or abandoned the site, send voidPurchase.
• If the Payment call was already sent, send cancelPayment.

Should we send getBenefits requests repeatedly as the basket changes?

Yes. Although the logic stays the same, discounts can vary as the cart changes. "Clean" the request data on each getBenefits call so the customer sees accurate benefits.

Do deals apply automatically after every getBenefits call?

Yes. Every getBenefits call returns the relevant deals so you can apply them to the customer's purchase.

When do we use itemCode vs dealCode in submitPurchase?

If your POS doesn't support external deals and discounts, you can configure a discount as an itemCode in your system to be added to a purchase. The same applies to dealCode: if you configure a deal in your system, Como returns the dealCode (or itemCode) in the submitPurchase response so the POS knows which discount item or deal code to apply.

Promotions & Deals

Can items be discounted as part of a deal?

Yes. Como has an advanced promotion system supporting item-level discounts, check-level discounts, special prices, and other combinations.

How do we define customizable items (modifiers) with Como?

Como doesn't currently support nested items for item modifiers. If you want to create discounts on certain modifiers, send each modifier as a separate item and use item tags to represent the "parent" items.

Does Como store or sync business menus?

Como doesn't store or sync menus regularly, but item numbers are inserted as part of the promotions configuration in the Como backend. All item codes inserted into Como can be saved as groups and reused for other promotions.

Do you prioritize benefits during a purchase?

Como does not perform conflict management — the choice is yours. In the Como Hub you can configure whether multiple deals can apply to one item or limit it to one. You can also choose whether to prioritize gifts, select a discount strategy, and decide how to calculate deals.

How are customer tags (in item and membership objects) used?

Tags are used for data purposes and can also be used for promotions. Membership tags are managed by Como.

General & Configuration

How can a customer learn the business's point accumulation scheme?

We highly recommend the business advertise all point accumulation schemes on its website and app. This helps customers understand and make the most of their purchases — a benefit to all parties.

Does Como support different menu languages?

Yes. Como passes the language in the web view parameter, so each time the POS page opens from Como, you can read the language parameter from the URL.