Request purchase limits

Purchase Limits lets you cap the number of units a single buyer can purchase across a set of products within a configurable time window. FastSpring's risk engine enforces the limit in real time at checkout. You don't need to change any code, and buyers can't bypass the limit by opening multiple browser sessions, tabs, or carts at the same time.

Why use purchase limits

How it works

At checkout, FastSpring checks the buyer's cumulative purchase history against the rule in real time.

flowchart LR
    A[Buyer starts checkout] --> B{Under the limit?}
    B -->|Yes| C[Checkout proceeds, no friction]
    B -->|No| D[Order blocked, message shown]

Because the check runs on FastSpring's back end, buyers can't get around it by opening multiple browser tabs, switching devices, or using a different payment method.

Configuration options

These are the decisions your account team turns into a rule. Select a field below to see what it controls, and have your answers ready when you request the rule (see Getting set up).

Passing the Player ID to FastSpring

To track by Player ID, you must send a unique buyer identifier with each checkout. You can use whatever identifier you already have for a buyer (player ID, gamer ID, account ID, and so on). FastSpring stores it under a tag. Your account team configures this tag's field name for your store, so you must send the identifier under that same field name, no matter which checkout method you use.

{
  "orderTags": { "customerId": "cust_1234" },
  "cart": { "lineItems": [ { "productPath": "gold-tier-cow", "quantity": 1 } ] }
}

{
  "tags": { "customerId": "secure_1234" },
  "items": [ { "product": "blue-cow", "quantity": "1" } ]
}

<script>
  fastspring.builder.tag({ "customerId": "sbl_1234" });
</script>

Choosing and mapping the tag field name

You send the identifier as a tag, and its key must match the value FastSpring has configured for your store. A FastSpring admin sets this in your store's Risk Assessment Settings, in the Gamer ID Tag Name Key field, labeled "the name of the session tag value which contains the unique gamer id" in the app. Whatever name your account team enters there becomes the key FastSpring looks for at every checkout.

These two must line up:

• the Gamer ID Tag Name Key configured for your store (set by FastSpring), and
• the tag key you send in your Sessions API orderTags, secure payload tags, or SBL fastspring.builder.tag(...) call.

For example, if your account team sets the Gamer ID Tag Name Key to customerId, every checkout must send { "customerId": "<your buyer id>" }. Your account team confirms the exact key with you when they configure your rule, so your developers know what to send.

Getting set up

Purchase Limits isn't self-serve yet. Contact your FastSpring account team to request configuration.

When you reach out, have the following ready:

• A short name for the rule, for your own internal reference
• The product or products you want to limit
• The maximum purchase quantity per buyer
• Your preferred time window and reset schedule (rolling or calendar)
• How to identify buyers: Player ID, Buyer Email, or Account ID (for Player ID, also the tag field name you want FastSpring to map)
• A start and end date, if you want to scope the rule to a specific period
• Your preferred buyer-facing message (purchase limit message or generic error)