White Label POS Due Diligence: 20 Technical, Commercial & Legal Checks Before You Sign

The three non-negotiable red lines: data export portability (can you get all your data out in a machine-readable format at any time without vendor assistance?), a mutual and enforceable termination-for-convenience clause, and a DPA that restricts the vendor and its sub-processors from using merchant data for training or resale. These three decide whether you own your merchant relationship or are renting it. If any of the three fails, flag the deal regardless of how competitive the rest of the terms look. They are the first checks to run because they are the most expensive to discover missing after signing.

A failing answer is any version of “we provide data export on termination for a fee” or “export is available in our proprietary format with vendor assistance.” That is not portability — it is a hostage situation. True portability means: (1) you can initiate the export yourself through the API or dashboard at any time, not just at termination; (2) the format is documented and machine-readable (CSV, JSON, or a documented API schema), not a proprietary binary that requires vendor decoding; and (3) there is no per-export fee that scales with your merchant base. If exporting your own data requires paying the vendor and waiting for them to process it, you do not own the data.

Run the 20 checks during the contract review, before signing. For each check, write down the vendor’s answer and classify it as pass, fail, or unclear. Unclear answers become questions for the vendor; failing answers become negotiation points. The leverage window is before signature — once you have committed your merchant base, your ability to negotiate drops sharply. Bring the written answers to the negotiation table; a vendor that is evasive on check 04 (data portability), 17 (PCI liability), or 19 (termination enforceability) is telling you where the risk lives.

Technical gaps can usually be worked around with engineering effort; legal gaps cannot be worked around at all — they are contractual facts. A missing API endpoint is annoying; a one-sided termination clause or narrow indemnification is existential. The legal checks (15–20) decide who eats the risk when something goes wrong: a breach, a compliance failure, a dispute with a merchant. ISOs skip legal review because it is less tangible than a demo, but the legal dimension is where the most expensive surprises live. If you only have time to review one dimension deeply, review the legal one.

A sandbox is a full, isolated test environment with its own test data, API credentials, and (ideally) production-equivalent functionality that you control and can use before and after signing to build and test integrations. A “staging environment upon request” is a vendor-controlled space, often with limited functionality, limited data, and access granted at the vendor’s discretion — typically after contract. The distinction matters because you need to build and test your integrations before you commit merchants to the platform, not after. Check 02 fails if sandbox access is not available before signature.

Yes — and this is the hardest discipline in due diligence. A great demo, competitive pricing, and strong technical capabilities do not offset a missing data portability right, a non-mutual termination clause, or a DPA that grants training rights on merchant data. Those three failures mean you do not control your own merchant relationship, and at exit you will discover that the leverage was never yours. The cost of walking away from a great-looking deal is one deal; the cost of discovering you cannot leave a bad contract with 200 merchants on it is your business. The three red lines are non-negotiable precisely because the downside of skipping them is unbounded.