Skip to content

Docs - Clean up Checkout use case page #33

@MantisClone

Description

@MantisClone

Problem

Checkout use case page contains AI warning, marketing fluff, placeholder links, speculative content, and "coming soon" notices that undermine credibility and user experience.

Key issues:

  • AI-generated warning box at top
  • Claims "80+ wallets" - needs verification against actual integration
  • Multiple "coming soon" placeholders (interactive quickstart, embed code, fork guide)
  • Claims "80+ tokens" conflicts with Payment Detection page's "150+ currencies"
  • Placeholder # links in cards
  • Code examples show non-existent @requestnetwork/payment-widget package
  • No tooltips for technical terms (crosschain, QR code, blockchain, etc.)
  • Section structure needs cleanup (too many tabs/accordions)

Proposed Solution

Apply Invoicing/Payment Detection cleanup template to Checkout page:

  • Remove AI warning box
  • Verify wallet support claim (likely referencing WalletConnect's 80+ wallets)
  • Update currency/token counts to match Payment Detection (150+ currencies)
  • Remove or clearly mark all "coming soon" content
  • Fix placeholder links or add notes for future pages
  • Replace code examples with accurate implementations (payment-widget doesn't exist as npm package)
  • Add tooltips for technical terms (wallet, crosschain, QR code, blockchain, escrow, etc.)
  • Simplify section structure (reduce tabs/accordions where possible)
  • Verify EasyInvoice demo link accuracy
  • Replace marketing language with factual, benefits-focused copy

Considerations

  • Checkout is a key use case - needs to be accurate about what's actually available
  • Payment widget exists in web-components monorepo, not as standalone package
  • "Coming soon" content should either be removed or moved to separate tracking issue
  • EasyInvoice demo at https://easy-invoice-demo.vercel.app/pay should be verified
  • Integration patterns should reflect actual implementation options (web-components, API direct)
  • Customer experience benefits should be factual, not speculative
  • Code examples should use actual Request Network packages and patterns

References

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

Status

✅ Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions