Founding proof blueprint
How should an ISO scope a white-label POS proof?
A practical blueprint for testing one merchant vertical, payment and device path, white-label surface, support model, AI workflow, and go/no-go evidence.
The proof unit
Small enough to control. Real enough to learn.
A sandbox demo can confirm that a screen exists. It cannot prove that merchant data arrives correctly, payments reconcile, staff adopt the workflow, support can diagnose a failure, or both companies can make the economics work. A useful proof is deliberately narrow but uses a real operator and the real operating path.
Blueprint fields
Nothing important stays implied.
Merchant case
Named operator, locations, vertical, current workflow, pain, sponsor, and repeatability hypothesis.
Scope
Included modules, use cases, integrations, brand surfaces, data, configuration, and explicit exclusions.
Payment path
Processor platform, gateway, application, device, boarding, transaction types, receipts, refunds, settlement, and status.
Ownership
Partner, Ankeva, merchant, and third-party responsibilities across onboarding, training, L1/L2/L3, incidents, billing, and continuity.
Evidence
Baseline, acceptance method, source, owner, frequency, threshold, exception, and final decision record.
Control
Dependencies, risks, change process, escalation, rollback or exit, stop conditions, approvers, and decision date.
Go / no-go evidence
Measure what scaling will multiply.
| Area | Example evidence | Decision it supports |
|---|---|---|
| Product | Required workflows completed with exceptions logged | Fit and remaining gap |
| Payments | Approved transaction types, refunds, receipts, settlement, and reconciliation verified | Route readiness |
| Implementation | Elapsed time, human effort, data cleanup, training, and blockers | Repeatability and cost |
| Support | Contact volume, severity, ownership, resolution, and merchant continuity | Service capacity |
| AI | Correct, rejected, overridden, uncertain, and escalated outcomes | Permitted control level |
| Economics | Actual activation, package, delivery cost, run cost, and payment effect | Commercial viability |
| Merchant | Adoption, observed outcome, unresolved pain, and willingness to continue | Value and next cohort |
The final record
A proof ends with a decision, not a vague success story.
Close the proof with verified results, limitations, unresolved dependencies, incidents, commercial changes, responsibility changes, and one explicit decision: scale the approved package, extend only a named dependency, pause, or stop. Any public case study then requires separate written permission and must preserve the scope and limits.
Questions buyers ask
Frequently asked questions
Why not begin with a portfolio-wide rollout?
A narrow proof exposes product, payment, data, implementation, support, and economics dependencies while the consequence is still containable. A portfolio promise made before those dependencies are measured moves discovery risk onto live merchants.
How many locations should a proof include?
Use the smallest number that represents the real workflow and operating complexity. Ankeva currently proposes one to three real locations as a discussion guardrail, not an industry standard or automatic contractual scope.
What makes a proof candidate qualified?
At minimum: a real merchant, focused vertical, reviewable payment and device route, product fit, accessible data or catalog, partner and merchant decision owners, support owner, measurable acceptance evidence, and a dated next step.
What should cause an immediate stop?
Stop when a critical payment, safety, legal, security, privacy, support, merchant-continuity, or scope condition fails; when required evidence is unavailable; or when no authorized decision owner accepts the next risk.
Use the framework on a real opportunity