Clean up Checkout use case page #37
Conversation
- Remove AI-generated warning - Improve overview with benefits-focused copy - Fix quickstart steps (payment processing clarity) - Update demo section with correct EasyInvoice URL - Convert integration approaches from tabs to card layout - Add Info callout linking to integration comparison - Update Key API Features (8 features, proper links, reordered) - Improve What's Next section (3 focused cards) - Replace emojis with proper icons in title - Fix all em-dashes to normal dashes - Add missing features: Query Requests, Payment Types Overview - Update all other use case pages to use icons instead of emojis
- Remove AI-generated content warning - Update chain count from '10+ EVM chains' to accurate '9 EVM chains' - Update currency count to '150+ currencies' for consistency - Rewrite Overview to lead with problem/solution (crypto payments lack context) - Add tooltips for technical terms (transaction hash, blockchain, webhook, confirmations) - Update 'When to Use' cards with accurate counts and clearer copy - Refine 'Common Scenarios' with minor improvements and tooltip - Add Info callout linking to technical details (replaces deleted section) - Update 'How Payment Detection Works' steps with tooltips - Add Info callout explaining Payment Detection powers all use cases - Remove 'Detection Features' section (technical details belong in API feature page) - Remove 'Detection-Only vs Full Workflows' Tabs (confusing framing) - Remove 'Implementation Example' code section (belongs in API Reference) - Remove 'Supported Networks & Currencies' section (have dedicated page) - Rename 'API Integration' to 'Key API Features for Payment Detection' - Reorder and update API feature cards for clarity - Update 'Next Steps' to 'What's Next?' with 3 focused cards - Link to welcome page demo showing payment collision prevention - Reduce page from ~310 lines to ~180 lines (42% reduction) Follows template from Invoicing page cleanup (PR #26) References Issue #29 and parent Issue #18
- Reduce from 5 steps to 4 steps focused on user journey - Remove technical implementation details (verification, confirmations, reconciliation logic) - Make steps more actionable and less technical - Update Info callout to explicitly link to technical details in API Features page - Leave complex explanations for dedicated API Features page
- Update Overview to explain reference-based payment detection - Clarify that 16-character payment reference is included in transactions, not Request ID - Update 'How Payment Detection Works' steps to reflect actual technical flow - Update all examples to use 'payment reference' terminology consistently - Maintain simplified language while being technically accurate Based on official docs: https://docs.request.network/request-network-api/payment-detection.md
Strategy: Use Case page uses user-facing 'Request ID' abstraction, API Features page will explain 'Payment Reference' implementation details. Changes: - Overview: Request IDs attach business context (not payment references) - Steps: Request ID is automatically embedded (abstracts payment reference mechanism) - Examples: All use 'Request ID' consistently - Maintains consistency with Welcome page vocabulary - Links to API Features page for technical deep dive Terminology strategy: - Request ID = user-facing identifier users interact with - Payment Reference = 16-char derived identifier for smart contracts - API Features page will explain the derivation and correlation - Use Case page focuses on what/why, not how This maintains technical accuracy while providing appropriate abstraction level for use case documentation.
- Replace 'embedded' with 'included in the transaction' (more precise, commonly used term) - Change 'request status updates and you receive webhook' to 'you receive webhook with payment details' - Avoids claiming request state changes (technically inaccurate - IPFS stores request state, payments detected via subgraphs, status derived from combining both) - Focuses on what user experiences (webhook notification) rather than internal state management
- Change 'included in the transaction' to 'connected to the transaction' - Fix tooltip formatting: move comma inside tooltip for 'transaction hash' - 'Connected' is more accurate and user-friendly than 'included'
- Reorder to prioritize e-commerce checkout (canonical use case) - Remove donations scenario (too niche) - Strengthen remaining scenarios with clearer value props New order: 1. E-commerce Checkout - high-volume, single wallet, many customers 2. SaaS Subscriptions - recurring payments, automatic renewals 3. Manual Invoices - integration with existing workflows, variable amounts Each scenario now emphasizes distinct value proposition and use case pattern.
Replace generic benefits with specific problem indicators: 1. Payment Collisions - Core technical problem (connects to welcome demo) 2. High Payment Volume - Scale problem where manual tracking fails 3. Wallet Management Overhead - Operational pain of separate wallets 4. Cross-chain Payments - Unified detection across chains without multiple APIs Each card now helps users self-identify if they have problems Payment Detection solves, rather than listing generic benefits.
- Remove AI-generated warning and marketing fluff - Rewrite Overview with checkout-specific problem/solution framing - Update to accurate metrics (9 EVM chains, 150+ currencies, 80+ wallets) - Replace tabs with scannable cards for integration approaches - Add 'When to Use Checkout' problem signal cards - Replace speculative content with 4 concrete scenarios - Remove non-existent features (Shopify plugins, code examples) - Add Info callout for commerce escrow (in development but marketed) - Update Key API Features to checkout-relevant features - Correct demo URL to https://checkout.request.network - Add tooltips for technical terms Closes #33
WalkthroughComprehensive rewrite of the Checkout use-case documentation page, including removal of AI-generated disclaimers, restructuring of quickstart flow, reorganization of API feature cards with updated terminology, expansion of scenario examples, and consolidation of section structure with new reference implementations and developer tools sections. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Areas requiring extra attention:
Pre-merge checks and finishing touches✅ Passed checks (5 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
- Quickstart: Clarified integration choice (Widget vs API), added non-custodial tooltip, noted webhooks only for API - Demo: Corrected wallet count based on wagmi.ts (6 direct + 400+ via WalletConnect), added Info comparing to EasyInvoice (490+ wallets) - Integration Approaches: Removed placeholder notes, improved copy from 'App builder platform' to 'Hosted platform for merchants', added real links - Digital Goods: Refocused on non-subscription examples (templates, photos, courses), added brief link to Subscriptions use case - Marketplace: Added link to batch payments feature - Key Features: Added Batch Payments card (critical for marketplace scenarios), removed note from Payment Widget card
- Renamed 'Checkout Demo' to 'Reference Implementations' - Split into two subsections: Checkout Demo and Easy Invoice - Removed detailed wallet counts (distracting from main point) - Reframed as 'what you can build' examples for developers - Emphasized different patterns: widget integration vs full app vs multi-tenant
- Easy Invoice: Individual merchants managing their own multiple sites - Fork EasyInvoice: Building multi-tenant platforms for other merchants - Updated demo description to match correct usage
Split previous 'Integration Approaches' into two sections: Integration Options (3 cards): - Easy Invoice: No-code dashboard + Client IDs for payment integration - Fork EasyInvoice: White-label platform for issuing to sub-merchants - Build with API: Full custom integration Developer Tools (1 card): - Payment Widget Button: React component usable with all integration options This separates architectural decisions from implementation tools.
- Easy Invoice and Fork EasyInvoice in 2-column layout - Build with API card below spans full width
When to Use Checkout (refactored): - Point-of-Sale Payments (was Immediate Payments - clearer) - Payment Splitting (new - unique to checkout) - High-Volume Attribution (was E-commerce Scale + Order Attribution combined) - Conversion Payments (was Multi-Currency Support - more specific) Common Scenarios (trimmed): - Reduced each example to 1-2 sentences - Removed redundant details and numbers - Fixed inconsistent content Also removed: - Commerce escrow Info callout (unreleased feature)
Changed from generic/confusing steps to specific Easy Invoice workflow: 1. Create account and generate Client ID 2. Integrate Payment Widget with Client ID 3. Customer completes payment 4. View confirmation in dashboard Added Info callout pointing to: - Payout API docs for custom API integration - Fork EasyInvoice for white-label platforms This provides clear, actionable steps for fastest path to production while guiding advanced users to alternatives.
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
use-cases/checkout.mdx(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Agent
🔇 Additional comments (8)
use-cases/checkout.mdx (8)
184-242: Consolidate or clarify the "Platform Fees" API feature card.In the "Key API Features for Checkout" section, the card layout includes:
- Line 188: "Payout Endpoints" (recommended for checkout)
- Line 204: "Batch Payments" (was "Crosschain Payments")
- Line 212: "Conversion Payments" (was "Platform Fees")
- Line 220: "Platform Fees" (still present)
There appears to be conceptual overlap or uncertainty: "Conversion Payments" was previously called "Platform Fees," but "Platform Fees" is still listed as a separate feature. Clarify whether:
- Both are distinct features and should both be present, or
- One should be renamed/consolidated to avoid confusion
Is this intentional, or does "Platform Fees" (line 220) conflict with the "Conversion Payments" card (line 212) that was previously titled "Platform Fees"?
9-20: Excellent rewrite of Overview section.The problem/solution framing in the Overview effectively differentiates Request Network's checkout from traditional crypto payments (instant attribution vs. manual reconciliation). The "What you get" bullets are concrete and relevant to the target audience.
Minor note: Ensure the link on line 20 to "/use-cases/welcome" exists and provides useful context—this should be verified as part of the link validation.
22-41: Quickstart flow is well-structured and aligns with PR objectives.The reframing from "Add Payment Widget" to "Create Easy Invoice Account" as the primary path is clearer and addresses the PR objective to clarify integration approaches. The Info box (lines 39-40) appropriately surfaces alternatives (Payout API, Fork EasyInvoice) without cluttering the main flow.
The four steps are logical and beginner-friendly.
43-64: Reference Implementations section is clear and well-positioned.The separation of Checkout Demo (pre-built example with interactive playground) and Easy Invoice (full dashboard application) provides two distinct reference paths. Descriptions are concrete and avoid marketing language, aligning with PR objectives to remove speculative content.
Pending: URL verification for both domains (already flagged above).
66-122: Integration Options tier is well-structured and clearly differentiates approaches.The three-option structure (Easy Invoice, Fork EasyInvoice, Build with API) effectively communicates different integration paths with appropriate value propositions for each. The Info box linking to detailed comparison docs is helpful contextual guidance.
Naming is clear: "No-code merchant dashboard," "White-label platform starter," and "Full API integration" convey intent without jargon.
162-182: Common Scenarios provides concrete, diverse examples aligned with PR objectives.The four scenarios (Online Store, Digital Goods, Event Ticketing, Multi-vendor Marketplace) are realistic and demonstrate different Request Network capabilities without marketing oversell. Cross-linking to Subscriptions and batch payments is contextually appropriate.
Examples are specific enough to help users self-identify their use case.
26-26: Production URLs verified as live and correct.Both external URLs are accessible with HTTP 200 status:
15-16: This review comment is incorrect—most internal links exist and metrics are consistent.Verification shows:
- ✓ 10 out of 11 internal links exist (use-cases/welcome.mdx, use-cases/subscriptions.mdx, and others all present)
- ✓ Metrics are consistent across docs: "80+ wallets," "9 EVM chains," and "150+ currencies" appear identically in checkout.mdx, invoicing.mdx, payment-detection.mdx, and resources/supported-chains-and-currencies.mdx
- ✓ Scenarios (lines 162-182) reference existing files: /api-features/batch-payments and /api-features/payment-detection both exist
One actual issue: /resources/integration-approaches does not exist in the repo—it's referenced in checkout.mdx but the file is missing.
Likely an incorrect or invalid review comment.
There was a problem hiding this comment.
Pull request overview
This PR performs a comprehensive cleanup of the Checkout use case page, removing AI-generated warnings, correcting inaccurate information, and restructuring content to match the proven patterns established in the Invoicing (#26) and Payment Detection (#32) pages.
Key changes:
- Removed AI warning and non-existent features (Shopify/WooCommerce plugins, non-existent npm package)
- Updated metrics to accurate values (9 EVM chains, 150+ currencies, 80+ wallets)
- Restructured integration guidance from a confusing mix of components and approaches into two clear tiers: Integration Options (3 architectural approaches) and Developer Tools (1 reusable component)
- Rewrote Quickstart to follow a specific EasyInvoice workflow instead of generic platitudes
- Reorganized demo section into "Reference Implementations" with clear subsections for Checkout Demo and EasyInvoice application
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
github-project-automation
bot
moved this from 🆕 New
to ✅ Done
in Request Network Tech Backlog
Problem
The Checkout use case page (#33) contained AI-generated warnings, inaccurate metrics, non-existent features, confusing integration options, and unclear audience targeting. Multiple sections had overlapping content, and the structure didn't match established patterns from Invoicing (#26) and Payment Detection (#32) pages.
Specific issues:
easy-invoice-demo.vercel.appinstead ofcheckout.request.network)Solution
Comprehensive cleanup following proven methodology from PRs #26 and #32:
Core Changes
Key Improvements
1. Reference Implementations (replaces Demo)
2. Integration Structure
3. Quickstart Path
Changed from generic/confusing to specific Easy Invoice workflow:
Added Info callout pointing advanced users to Payout API and Fork options.
4. Eliminated Overlap
5. Integration Clarity
Additional Improvements
Considerations
Integration Options Accuracy:
Quickstart Trade-offs:
Removed Content:
Why This Matters
User Impact:
Content Quality:
Related:
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.