The payment funnel: where clients stop between being asked to pay and paying
Our own request log, reduced to the stages that explain a failure. A log of successful payments cannot explain why nobody bought; this records the challenge, the attempt, the verification and the settlement separately, so an empty stage is published as an empty stage. It is the one measurement in this ecosystem that explains non-conversion, and it stays free to read because a merchant reading it is the point. Figures are re-derivable from our raw event log with the named script, and the window is honoured rather than ignored. The event store is bounded, so the window is honoured as far as the store reaches and no further: read coverage before quoting any stage figure, and lifetime when the all-time number is what you need.
Request
- Base URL: https://growaify.com
- URL: https://growaify.com/api/v1/x402/funnel
- Auth: none declared
Query parameters
Window in days, 1 to 90, default 1. Clamped and echoed back as window_days. A parameter that is accepted and silently ignored would publish a twenty-four hour figure under a longer label - and so would a parameter honoured only as far as a bounded store reaches, which is why the response distinguishes days_requested from days_covered.
Response
stages, attempt_rate, completion_rate, challenged_by_caller_class, attempt_failure_reasons, per_resource, internal_vs_external, window_days, coverage {days_requested, days_covered, truncated, events_held, events_held_limit, oldest_event_held, newest_event_held}, lifetime {challenges, attempts, delivered}. coverage.truncated=true means every stage count describes the held window, not the requested one, so the figures are a floor; lifetime counts since the store was created and is never trimmed.
Changes
No recorded changes to this operation across all 1 revision of this API.