docs: publish payment destination + secure payment link integration guide

[AllenAJ]

Summary

• Port internal Notion guide into public Mintlify docs
• Added end-to-end flow: wallet sign-in, payment destination, client ID, webhooks, secure payment link creation, optional status check
• Linked existing webhook/auth references to avoid duplication

Why

Integration partners currently need manual access to internal docs. This makes onboarding self-serve in public docs.

Test plan

• Previewed page locally with Mintlify
• Verified links and rendering

Closes #81

[greptile-apps]

Greptile Summary

This PR replaces the previous "Quick start"-style secure payments guide with a comprehensive end-to-end onboarding walkthrough covering wallet sign-in, payment destination creation, Client ID generation, webhook setup, and secure payment link creation. The rewrite is well-structured and meaningfully improves self-serve discoverability for integration partners.

Key findings:

• destinationId naming inconsistency (P1): Step 2 labels the value returned by Dashboard as destinationId (equated to humanReadableInteropAddress), then tells users to "Save it for Step 5." Step 5 defines the API field destinationId as humanReadableInteropAddress:tokenAddress — a composite that includes the token address. A reader who saves the Step 2 value and uses it directly in the Step 5 API call will submit an incomplete identifier. The distinction between the two should be made explicit.
• Flow diagram missing Step 6 (P2): The ASCII art overview diagram documents only 5 steps; the optional "Check payment status" Step 6 is absent from the diagram.
• <Steps> component not used (P2): AGENTS.md requires Mintlify's <Steps>/<Step> components for numbered sequential procedures. All sub-instruction lists in Steps 1–5 use plain Markdown numbered lists instead.
• <RequestExample> / <ResponseExample> / <ParamField> not used (P2): AGENTS.md requires these components for API endpoint documentation. Request/response examples and parameter tables throughout the guide use plain code blocks and Markdown tables instead.

Confidence Score: 3/5

• Hold for the destinationId naming inconsistency — users who follow the guide literally may submit malformed API requests.
• One concrete content bug (the destinationId Step 2 vs Step 5 mismatch) directly affects the primary user path: a developer who saves what Step 2 calls destinationId and passes it straight into the Step 5 API request body will receive an error because the token address is missing. This breaks the main flow. The remaining issues are style-guide compliance items that do not affect functionality but should be addressed to maintain docs consistency.
• api-features/secure-payment-integration-guide.mdx — specifically the destinationId description in Step 2 (line 75) and its relationship to the construction instructions in Step 5 (lines 194–212).

Important Files Changed

Filename	Overview
api-features/secure-payment-integration-guide.mdx	Complete rewrite of the integration guide as an end-to-end onboarding flow; contains a key naming inconsistency for destinationId between Step 2 and Step 5 that could cause API call failures, plus the flow diagram is missing Step 6 and several sections don't use the required Mintlify components (<Steps>, <RequestExample>, <ParamField>).

Sequence Diagram

sequenceDiagram
    actor Dev as Developer
    participant Dash as Dashboard<br/>(dashboard.request.network)
    participant Auth as Auth API<br/>(auth.request.network)
    participant Portal as Portal<br/>(portal.request.network)
    participant API as Request API<br/>(api.request.network)

    Dev->>Dash: Sign in with wallet (Step 1)
    Dash-->>Dev: wallet session cookie (session_token)

    Dev->>Dash: Create payment destination (Step 2)
    Dash-->>Dev: humanReadableInteropAddress (destinationId)

    Dev->>Auth: POST /v1/client-ids (Step 3)
    Auth-->>Dev: clientId

    Dev->>Portal: Configure webhook endpoint (Step 4)
    Portal-->>Dev: webhook signing secret

    Dev->>API: POST /v2/secure-payments<br/>x-client-id: clientId<br/>destinationId: humanReadableInteropAddress:tokenAddress (Step 5)
    API-->>Dev: requestIds, securePaymentUrl, token

    Dev->>Dev: Share securePaymentUrl with payer

    Portal-->>Dev: Webhook event (payment.confirmed / payment.partial)

    opt Step 6 – optional polling
        Dev->>API: GET /v2/request/{requestId}
        API-->>Dev: hasBeenPaid, txHash
    end

Loading

_{Reviews (1): Last reviewed commit: "docs: publish end-to-end payment destina..." | Re-trigger Greptile}