Customer page guide

People remember pictures, not shop names. Successful listen receipts include the merchant domain URL and QR. Ask customers to screenshot into Photos immediately: later they reopen Photos to order again, or share so friends scan straight in — closer to real habits than searching a platform.

• Customer pages: visitors open your bound business domain (CNAME to 302wallet.com), not idnwallet.com
• This site: merchant signup, configuration, publishing, and App downloads only
• Before go-live, finish CNAME verification (claim digital identity) and publish from the portal or App Ops

The domain home / shows enabled services (coupon / dining / rooms / car rental) from your portal modules. When a business card is published, the page also shows the electronic card.

1. Visitor picks a service (or views the card)
2. For listen modules, enters phone number and confirms it again (contact only — not payment)
3. Continues into that flow

1. Choose Coupon on the home page and browse available offers
2. Open details and tap Claim
3. Redirect to the voucher page /voucher (QR code)
4. Screenshot or download the image; staff redeem with the coupon redeem App

Visitors can return home for another coupon if quota remains.

1. Merchant configures name, title, address, and phone for a card domain in the portal, then publishes
2. Visitors open that card domain to view the electronic business card
3. Phone / address links can open directly for contact
4. Screenshot recommended to keep contact details

One card = one independent domain (shop verification not required). Can run alone or with coupons / dining.

1. Open /order, browse the menu, and build a cart
2. Confirm contact and address fields
3. Tap Send dining info — the platform forwards only; no payment
4. Success is a one-time receipt: closed pages cannot be reopened — screenshot required

Merchants receive orders in the merchant App. See Merchant Apps.

1. Open /room and pick a room type
2. Enter guest name and check-in / check-out dates
3. Tap Send booking info — forward-only, no charge
4. Success receipt cannot be viewed again after close — screenshot

Handled in the unified merchant App room workbench.

1. Open /car and pick a vehicle type
2. Enter pickup / return time and contact details
3. Tap Send rental info — forward-only, no charge
4. Success receipt cannot be viewed again after close — screenshot

Handled in the unified merchant App car workbench.

1. Sign in to the merchant portal; confirm CNAME detection passed and modules are published
2. Open your business / card domain on a phone browser (test apex and www)
3. Walk through claim / card / dining / rooms / car rental for enabled modules
4. Check copy, prices, catalog, and card details match the portal or App Ops
5. Confirm the App receives dining/room/car info; redeem a test coupon with the redeem App

• The wallet does not store dining / room / car history; closed receipts cannot be recovered
• Payment is arranged between merchant and customer; the platform does not clear or custody funds
• Public service phone on the customer page can differ from the login phone (set in portal profile)
• Day-to-day dish / room / vehicle / coupon edits: use merchant App Ops; changes publish to the customer page
• Business card edits: save in the portal Cards module, then publish

• Domain is not the customer UI: check CNAME to 302wallet.com and portal detection — CNAME guide
• No dining / room / car entry: enable the module in the portal and publish
• No business card: confirm the card is published and the domain CNAMEs to the claim node
• Stale content: publish after edits; hard-refresh the browser
• App gets no orders: App domain must match the portal binding; Ops edits need a valid portal session

Also see the FAQ and publishing guide.