A purchase is money; an entitlement is the access it buys
Here's the idea in one breath: when someone pays, that's money. What the money unlocks is a separate thing — and that thing has a name. The name is the entitlement. You define it once, as a short key like pro, and from then on your app asks "does this person have pro?" — never "did they pay on Stripe in March?"
Keeping the access separate from the purchase is the whole trick. It's what lets one pro be unlocked by a Stripe subscription, an Apple purchase, or a hand-given grant — all the same to your code. You'll see exactly that in the next two lessons. First, you give the access a name.
Name it once in the dashboard
In your Crossdeck dashboard, open Entitlements → New entitlement and type the key. Watch the film for the click-through — it takes about ten seconds.
The key is permanent and case-sensitive, because it's the exact string your code will check. Pick the same word you'll use in the app:
// the entitlement you create in the dashboard is the same string here
if (Crossdeck.isEntitled("pro")) {
showProFeatures();
}
The middle layer that keeps everything honest
The entitlement sits in the middle of three layers: the product (what was bought, mirrored from your rail), the entitlement (the access — the name you just created), and your code (which only ever checks the name). One entitlement can be granted by many products, and your app never has to know which one — it just asks for pro.
One tip that saves pain later: name the capability, not the plan. Call it cloud_sync or pro, not tier_2. When you re-jig pricing next year, the capability is still the capability — your gates don't move.
An entitlement, ready to wire up
Your new entitlement now appears in the Entitlements list — ready for the next two steps: a product will grant it, and your code will check it.
The access has a name. Next, point a product at it so a purchase grants it automatically.