# Map products to entitlements

Connect what people buy to what it unlocks. Point the product they purchase at the entitlement it should grant — and a purchase grants that access automatically, from any rail.

Source: https://cross-deck.com/university/map-products-to-entitlements/
Verified Crossdeck University lesson — prose plus real, runnable code.

## Draw one line: this purchase unlocks that access

You've named the access — pro. Now you connect it to the thing people actually buy. The good news: you don't recreate your products here. The moment you connect a rail (Stripe, Apple, Google), Crossdeck pulls in your products automatically. They're already sitting in your catalog, waiting. All you do is draw one line: buying this product → unlocks pro.

Draw that line once and every future purchase of that product grants the access on its own. You never write a webhook handler, never reconcile a payment by hand. That's the payoff you'll watch in the film.

## Point the product at the entitlement

In the dashboard, open Products, pick the product your customers buy, and under Grants entitlement choose pro. That's the whole mapping — watch the film for the click-through.

Two things worth knowing as you do it:

One product can grant several entitlements, and one entitlement can be granted by several products. That second part is the magic: map your Stripe subscription and your Apple in-app purchase both to pro, and a customer who buys on either rail gets the same access. Your code still only ever asks for pro.

## The mapping is the join that turns money into access

The chain is short and one-directional: a purchase lands → it belongs to a product → the product grants an entitlement → the customer has it. The mapping you just drew is the middle link.

It's safe to run twice. Crossdeck hashes each product's data and only writes when something changed, so a re-delivered webhook or a re-run backfill is a no-op — your catalog can't drift from ingesting the same thing again.

One shape to watch: if you've modelled monthly and yearly as two prices on a single Stripe product, they map as one row — same features, different cadence, which is usually exactly right. If you genuinely need different feature gates for monthly vs yearly, split them into two products on the rail side first; then you'll have two rows to map separately.

## A real purchase now grants access

Open a customer who owns that product. The entitlement now reads as active on their record — granted by the purchase, automatically.

pro · active
 Their purchase → the product → pro. The same mapping works for a Stripe sub or an Apple purchase — one access, any rail.