0060b16912
In-house Request Network checkout went fully end-to-end on dev today. A real 0.01 USDC payment flowed through wallet connect -> approve -> ERC20FeeProxy.transferFromWithReferenceAndFee -> RN webhook -> TransactionSafetyProvider -> Payment.status=completed -> page success state. Tx 0x494c77a29161b5100d8e0b1ac675f1822955d0bb3633ecdbfafb886f84f2f320. Docs: - New PRD: Wallet, Multichain, Confirmations, AML, Trezor (5 follow-ups, each sized for an independent contributor) - Updated PRD: Request Network In-House Checkout (phases 0..3 done, phase 4 partial, phases 5-6 not started) - Updated handoff: deployed versions, what is working end-to-end, follow-up tasks index Taskmaster: 5 new top-level tasks (#7..#11) covering ephemeral destination wallets, multichain proxy registry + USDC/USDT, runtime confirmation thresholds, optional seller-paid AML screening, and Trezor signing for admin actions. Tasks are scoped fine-grained so each is independent enough for kimi to pick up. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2.4 KiB
taskmaster_id, status, priority, depends_on, parent_id, source, generated_at
| taskmaster_id | status | priority | depends_on | parent_id | source | generated_at | |
|---|---|---|---|---|---|---|---|
| 3 | done | high |
|
taskmaster | 2026-05-28T11:49:27.076Z |
3 - Migrate payment architecture toward Request Network and internal funds management
- 3 - Migrate payment architecture toward Request Network and internal funds management #taskmaster #priority/high #status/done ⏫ 🆔 tm-3 ⛔ tm-2
Metadata
| Field | Value |
|---|---|
| Taskmaster ID | 3 |
| Status | done |
| Priority | high |
| Dependencies | 2 |
| Parent | None |
Description
Plan and implement provider-neutral payment flows, Request Network pay-in support, funds ledger, webhook reconciliation, release/refund orchestration, UI migration, and SHKeeper decommissioning.
Details
Source PRD: .taskmaster/docs/prd-request-network-migration-and-funds-management.md. The PRD recommends phased migration behind a provider adapter, Secure Payment Pages first, platform-controlled escrow/payee destination, and a first-class internal funds ledger before release/refund enforcement.
Post-completion update: Task 3 now includes a CI-safe focused verification command for the provider-neutral payment migration plus optional Trezor safekeeping. Trezor safekeeping is optional by default via TREZOR_SAFEKEEPING_REQUIRED=false and only gates release/refund confirmation when explicitly enabled. Vault references: 04 - Flows/Trezor Safekeeping Flow.md, 03 - API Reference/Trezor API.md, and 08 - Operations/Payment and Trezor Verification Report.md.
Verification
Use feature flags, provider fixture tests, webhook signature/idempotency tests, ledger invariant tests, migration dry-run reports, and limited cohort rollout before default provider switch.
Focused verification command: npm test -- tests/payment-adapter-registry.test.ts tests/request-network-adapter.test.ts tests/request-network-payin.test.ts tests/request-network-webhook.test.ts tests/payment-ledger.model.test.ts tests/payment-ledger.service.test.ts tests/payment-migration.service.test.ts tests/payment-release-refund-orchestration.test.ts tests/payment-release-refund-routes.test.ts tests/payment-reconciliation.service.test.ts tests/payment-observability-redaction.test.ts tests/payment-observability-events.test.ts tests/trezor-safekeeping.service.test.ts --runInBand. Expected result: 13 suites, 64 tests passing. Also run npm run typecheck.