Switchpoint Payments Business Plan — Product, Technology and Security
The routing engine, the dual-rail architecture, PCI DSS scope and the security posture a merchant acquirer must be able to evidence.
Product, Technology and Security
Jump to section
- Overview & contents
- i. Important Notice and Basis of Preparation
- 1. Executive Summary
- 2. The Opportunity
- 3. Market and Regulatory Context
- 4. Product, Technology and Security
- 5. Go-to-Market and Unit Economics
- 6. SWOT and Competitive Position
- 7. Financial Projections
- 8. Cash, Funding and the Balance Sheet
- 9. Sensitivity and Scenario Analysis
- 10. Risk Analysis
- 11. Regulatory, Compliance and Licensing
- 12. Organisation and Management
- 13. Implementation Roadmap
- 14. Key Performance Indicators
- 15. The Offer, Returns and Recommendation
- 16. Assumption Register
- A. Appendix A: Consolidated Financial Summary
- B. Appendix B: Volume, Pricing and Unit Economic Schedules
- C. Appendix C: Funding, Cash and Balance Sheet Schedules
- D. Appendix D: Risk Register
- E. Appendix E: Glossary
- 4.1 The merchant proposition
- 4.2 Architecture and security
4.1 The merchant proposition
A merchant contracting with Switchpoint receives a single agreement, a single settlement account, a single reconciliation ledger and a single support relationship covering both rails. That consolidation is the product. The individual components are not novel; the integration is.
|
Component |
What it does |
Why it matters to the merchant |
|---|---|---|
|
Card acceptance |
Card-present acceptance through certified terminals at the counter, with card-not-present for telephone and account-customer transactions |
The rail the merchant already expects. Terminals are offered on rental or outright purchase |
|
Account-to-account request-to-pay |
The merchant initiates a payment request from their own system; the customer authorises in their banking application |
Irrevocable cleared funds within seconds, at a capped fee rather than a percentage of value |
|
Single settlement account |
Both rails settle to one designated account |
Removes the reconciliation of two payment streams against one sales ledger |
|
Structured reference on every transaction |
The merchant controls the reference, generated from the source system |
Eliminates the mistyped reference, the forged proof of payment and the manual match |
|
Payouts and reconciliation module |
Supplier and refund disbursement, and automated matching back to the source system |
The subscription line in the revenue build, and the stickiest part of the product |
|
Embedded in the merchant’s own software |
Acceptance appears inside the practice management or trade-counter system |
No separate login, no separate workflow, and no separate persuasion at the point of sale |
4.2 Architecture and security
▪ Ledger first. A double-entry transaction ledger is the core of the platform, with both rails writing to it. Settlement, reconciliation and merchant reporting are read from one authoritative record rather than assembled from two.
▪ Cardholder data scope minimised. Card data is tokenised at the terminal and never traverses Switchpoint infrastructure in the clear, which is what makes PCI DSS Level 1 attestation achievable within the modelled timetable and cost.
▪ Partner integration by application programming interface. Vertical software vendors integrate once and enable merchants without further engineering, which is the mechanism by which acquisition cost falls as the channel matures.
▪ Settlement funds segregated. Merchant funds are held in a designated settlement account, are not company money, and are matched by an equal and offsetting settlement liability on the balance sheet.