How to add prediction markets without rebuilding your platform
The screen is the cheap part. Behind it sit eight layers of infrastructure that have to keep running after launch day. Here is what they are, and how to take all eight without rebuilding what you already have.
In this article 4 sections
Every operator that looks seriously at prediction markets meets the same problem: the category looks like a feature and costs like a platform. It is easy to underestimate, because the front end is a list, a ticket and a portfolio, and a capable product team can draw those in a sprint. The screen is the part that finishes. Almost everything behind it has to keep running.
The eight layers behind the screen
- Venue relationships and data rights
- Public market data does not by itself grant the right to redistribute it or execute against it. Commercial agreements come before code.
- Ingestion and normalisation
- Venues disagree about what a market is and change shape without warning. One event model, kept current, is continuous work.
- Pricing and quotes
- The number on a card and the number a customer can trade at are different numbers. Confusing them is invisible until somebody is charged.
- Execution
- A limit on what the order will pay, idempotency so a retry cannot double a wager, and a clean refusal when the market has moved.
- Positions and marks
- An entry price that never changes beside a mark that always does, for every customer, continuously.
- Early exit
- Selling a position back before resolution at a market price, with the same protections as the entry.
- Resolution and settlement
- Markets resolve on their own timetable. Every result has to reach your ledger exactly once, including when a message is delivered twice.
- Reconciliation and reporting
- Months later, you need to explain why a position paid what it paid, from records rather than memory.
Whose business the eight layers are
Building all eight makes sense only when prediction markets are the business itself: when you intend to hold venue relationships, staff a market operations team and sell the infrastructure. For a sportsbook or a casino, the customer, the wallet and the licence are the business, and prediction markets are inventory for them. Then the eight layers are cost rather than differentiation, and the only useful question is how small your side of the integration can be.
How Parity removes the rebuild
On Parity, all eight layers sit on Parity's side of the line. Your side is three things:
- A session endpoint
- One server-to-server call, made after your own sign-in, that maps your customer to a browser-safe token. Parity never authenticates your customers and never sees a credential.
- The surface and a listener
- An iframe on the origins you register, drawn in your mode, accent colour, corner radius and density, plus a message listener on your page. Market list, ticket and positions are drawn for you.
- A settlement webhook
- Settlement records pushed to your endpoint, signed and retried, safe to apply twice without paying a customer twice.
Teams that would rather draw the interface themselves use the same account through the prediction market API and its TypeScript client. The boundary does not move between the two. A sandbox can be driven to outcomes that have not happened yet, so the integration is tested end to end before a real market resolves.
What it costs, counted honestly
A fair build estimate counts the run cost, not just the launch: the people who keep ingestion current, watch settlement, answer the support ticket about a price that moved, and keep the venue agreements in place. Parity is priced per integration, set by the volume you run and the surfaces you take, so the comparison is a known rate against an open-ended team. The rate for your volume, and the plan from signature to launch, are the first things a demo call covers.
For the integration detail, read prediction market APIs: what you actually need to integrate, and for keeping customer money where it is, prediction markets on one wallet. The full responsibility split is on the integration overview.
