The Invisible Revenue Funnel Stage: Where Payments Disappear

A customer can intend to pay without becoming recognized revenue. Between those two points, authentication, bank transfer, receipt submission, manual review, or a temporary failure can leave a real buyer stranded in an invisible stage.

Your revenue funnel is more than visits and purchases

Many SaaS dashboards reduce the funnel to visits, sign-ups, payment starts, and revenue. But starting a payment is not the same as finishing one. If intermediate states do not exist in the data model, the customer disappears from operations: sales still sees intent, accounting sees no revenue, and support does not know what to do next.

Replace counters with an explicit state machine

The fix is not another total. Model the payment journey as explicit states. Stripe’s PaymentIntent lifecycle separates states such as requires_payment_method, requires_confirmation, requires_action, and succeeded. Your product should define business equivalents that fit its payment methods.

For a manual payment, one useful path is:

intent_created → instructions_shown → proof_received → awaiting_review → approved → revenue_recorded

Also define rejected, expired, and needs_customer_action paths. Names can vary, but each payment should have one current state and an auditable history of transitions.

Make every state actionable

A table full of “pending” payments is visible but not operational. Every intermediate state needs an owner, next_action, due_at, and reason. Instead of “seven payments pending,” the dashboard should say “three receipts need accounting review, two customers need bank details, and two attempts expired.”

This is how a useful “What needs your attention today?” queue is built: surface records whose deadline passed, whose state is stuck, or that received new evidence.

Keep payment metrics separate

Payment intent count, proof received count, approved payment count, and recognized revenue are different metrics. Conversion must be calculated between explicit stages. Combining them makes activity look like revenue.

Store two timestamps: event_time for when the event actually happened and observed_at for when your system received it. This matters for bank transfers and backfills, where yesterday’s payment may appear in your system today.

Test scenarios before trusting the dashboard

Run at least these paths with test data: immediate success, customer action required, receipt plus manual approval, rejected proof, expiry, and recovery from error. Verify that no state is left without an owner or next action and that revenue increases only in the final approved state.

At the end of each day, reconcile the provider or bank state, the payment record, and the revenue ledger. A mismatch should create an alert, not disappear behind a default value.

Quick answers

Should every created payment count as revenue?

No. A created payment is the start of a process. Count revenue only after the final state meets your accounting policy.

What is a good state for a manual payment?

Use an explicit state such as awaiting_review or proof_received, with an owner, deadline, reason, and next action—not an ambiguous pending label.

Conclusion

The invisible stage appears when a system records only the beginning and end of payment. A state machine, action queue, and reconciliation loop keep every customer visible until the payment is truly resolved.

Official source

Stripe: PaymentIntent lifecycle https://docs.stripe.com/payments/paymentintents/lifecycle