Customer Journey: Paying Merchants with Asgaya
đź“– Unfamiliar terms? See the glossary for definitions.
Role: Active BCH Buyer
Example: Ana (customer) pays Carlos (merchant) for groceries
Overview
A customer uses Asgaya to pay a merchant with BCH. The mechanism depends on whether the customer already has BCH:
- Has BCH: Direct wallet-to-wallet payment (simplest)
- Needs to buy BCH: Covenant-based flow (better UX - coordinates customer, seller, merchant automatically)
Mode: Active - uses the app when they need to make a payment
Two Flows, Two Mechanisms
Flow 1: Customer Already Has BCH → Direct Payment
When to use: Customer has BCH in their Asgaya wallet
Flow:
- Merchant tells customer amount (e.g., “€20 for groceries”)
- Customer opens Asgaya
- Customer enters merchant’s Cash Account (e.g.,
Carlos#187) and amount
- Customer sends BCH directly to merchant (standard BCH transaction)
- Merchant’s wallet receives BCH instantly (0-conf)
- Done
Time: 30 seconds
Why direct payment: Simplest mechanism - one transaction, no coordination overhead
Flow 2: Customer Needs to Buy BCH → Covenant for Better UX
When to use: Customer doesn’t have BCH and needs to buy from passive seller first
Why covenant: Coordinates three parties (customer, seller, merchant) automatically. Customer takes one action (pay seller), then everything else is automated.
Flow:
- Merchant tells customer amount (e.g., “500,000 VES for groceries”)
- Customer opens Asgaya: “Pay with Asgaya”
- Customer enters merchant’s Cash Account and amount
- Customer creates covenant (merchant as recipient)
- Customer selects passive BCH seller (or app auto-selects best rate)
- Customer pays seller (via Bizum, cash, or preferred payment method)
- [AUTOMATIC] Seller’s app detects payment
- [AUTOMATIC] Seller funds covenant with BCH (seller locks their own BCH, just like in the remittance flow)
- [AUTOMATIC] Merchant gets notification
- Merchant accepts BCH from covenant
- Done
Time: 1-3 minutes (mostly waiting for seller’s bot to detect payment)
Why covenant is better here:
Without covenant:
- Customer buys BCH → BCH lands in wallet → Customer manually sends to merchant
- Two steps for customer, two transactions
With covenant:
- Customer creates covenant → pays seller → everything else automatic
- One action for customer, then protocol coordinates the rest
The covenant isn’t technically necessary, but it provides superior UX. The customer doesn’t need to manage BCH in their wallet - they pay the seller, and the protocol handles getting BCH to the merchant automatically.
Customer vs Sender: What’s the Difference?
| Aspect |
Customer |
Sender (Remittance) |
| Recipient |
Merchant (business) |
Family/friend (individual) |
| Context |
Payment for goods/services |
Money transfer |
| Location |
Often same place (in-person) |
Different countries |
| Technical flow |
Flexible: Direct (if has BCH) or Covenant (if buying BCH) |
Always covenant (sender → covenant → recipient claims) |
| Settlement |
Instant or near-instant (<3 min) |
Delayed (recipient claims when ready, hours/days) |
| Mechanism choice |
Optimized for UX (simplest for each scenario) |
Always covenant (geographic separation requires it) |
Key differences:
- Customer payments are flexible: Direct send when customer has BCH (simplest), covenant when customer needs to buy BCH first (better UX - automated coordination)
- Remittances always use covenants: Sender and recipient separated by geography and time, covenant provides the necessary coordination layer
- Both valid: Each flow uses the mechanism that provides the best user experience for that scenario
Use Cases
As the Asgaya merchant network grows, several commerce use cases emerge beyond basic remittances:
Core Commerce Scenarios
- Tourist Payments - International travelers paying local merchants when cards don’t work abroad
- Cross-Border Living - Retirees, digital nomads, and remote workers earning in one currency, spending in another country without conversion
- Merchant as ATM - Using merchant network for global cash access (cash in/out anywhere)
- Informal Economy Access - Cash-based commerce for those without banking access
Future Scenarios
More use cases will emerge as merchant network density increases. Each scenario leverages the same infrastructure - the merchant network is the innovation, mechanisms adapt to context.
Traditional e-commerce: Customer abroad pays online merchant (same as tourist, different medium)
Fee avoidance: Customer pays merchant with Asgaya instead of card (merchant saves 2-3% processing fees)
Phase 0 Status
This flow is NOT a Phase 0 priority.
Phase 0 focus: Remittances
Phase 1+ expansion: Commerce flows
Why remittances first: Building the remittance flow creates the infrastructure for all other use cases. By serving remittance users, we automatically enable:
- Customer payments (same merchant network, simpler flow - direct BCH instead of covenant)
- ATM network (merchants provide cash-in/cash-out for travelers)
- Cross-border commerce (tourist pays local merchant)
- All intermediate flows (same infrastructure, adapted mechanisms)
Remittances bootstrap the entire ecosystem. Once merchants exist to serve recipients, customers can use those same merchants for commerce and currency exchange. Customer flows are actually simpler (direct BCH transfer) than remittances (covenant-based).
⚠️ Technical Note: Covenant Confirmation Delay (2026-07-26)
Issue discovered: The covenant-based customer flow (Flow 2) assumes near-instant covenant activation, but blockchain confirmation takes ~10-15 minutes.
Impact on Flow 2 timing:
- Original estimate: 1-3 minutes (seller bot + coordination)
- Actual with confirmation: 15-18 minutes (unacceptable for point-of-sale)
Implications:
- 0-conf approach: Seller funds covenant (0-conf), merchant claims (0-conf) → maintains 1-3 min UX but requires accepting unconfirmed transactions
- 1-conf approach: Wait for confirmation → 15+ min (breaks point-of-sale UX)
Resolution strategy:
- Phase 0: Focus on remittance flow (recipient willing to wait for confirmation)
- Phase 1+: Revisit customer flow with either:
- App logic + Nostr coordination (without covenant, or simpler covenant)
- 0-conf acceptance model (merchant risk tolerance)
- Pre-funded covenant mechanisms
- Customer buys BCH in advance (not at point of sale)
For now: Customer flow design is DEFERRED pending remittance flow validation.
âś… Update: 0-Conf Validation (2026-08-02)
Testing results: 0-conf covenant transactions proven working on testnet3
What was tested:
- 3 successful covenant refunds with 0-conf (unconfirmed funding transactions)
- Transactions worked for small amounts (€7 equivalent)
- User experience: instant (no 10-minute wait)
Implications for customer flow:
- 0-conf is viable for point-of-sale customer payments (€5-50 range)
- Merchant risk is minimal for small transaction amounts
- Maintains 1-3 minute UX target (acceptable for commerce)
- Larger amounts can require confirmation if merchant prefers
Recommendation: Phase 1+ customer flow should use 0-conf for small amounts, with merchant-configurable confirmation thresholds for larger transactions.
For detailed covenant mechanics: See Sender Journey - same underlying mechanism, different context.
Related: Sender Journey, Merchant Journey, Trader Journey
Status: Phase 1+ (customer flow designed, 0-conf validated, deferred pending remittance validation)
Updated: 2026-08-03
Navigation
Related: Merchant