Stop coupon and promo code abuse
A one-per-customer code is only one per customer if you can tell who the customer is. Ask at redemption time and the answer arrives before the discount is granted.
Why your billing system cannot catch it
Stripe, Paddle and every other billing system will happily enforce one redemption per customer record. The abuse works by making more customer records. Five accounts, five first-time redemptions, all of them valid as far as billing is concerned, and each one a real discount off real revenue.
The question your billing system cannot answer is whether those five records are five people. That is an identity question, and it is the same one OneTrial already answers at signup.
Ask at redemption, not at signup
Send the redemption as its own kind of event. The code travels with it, along with the account id you already have, so the answer is about this person and this code rather than about a signup that happened months ago.
POST /api/v1/decisions{"event": "promo","promoCode": "WELCOME50","email": "person@example.com","ip": "203.0.113.7","visitorToken": "…","userId": "usr_8213"}
What comes back is the usual three answers. A borderline case gets challenged rather than refused, because a real customer clears a challenge and someone on their fifth account usually will not.
{"decision": "challenge","score": 54,"reasons": ["V_PROMO_REUSE_CLUSTER","D_DEVICE_REPEAT"],"challengeOptions": ["email_verify", "captcha"]}
A redemption is not a trial
This distinction is the reason the feature needed engine work rather than a wrapper. A redemption is recorded as its own kind of event and never counts as a consumed trial. Without that, a paying customer who redeems a coupon would acquire a second trial on their own card and device, and every later decision about them would read it as a repeat. Your best customers would be the first people the system turned on.
The code itself is deliberately not treated as an identity. A public campaign code is shared by thousands of unrelated people, so linking accounts by the code they typed would join strangers into one cluster on the strength of a marketing campaign. The code is evidence about a person only when that person is already linked to an account that redeemed it.
Write the policy yourself
The score decides by default. When you want something specific, say it in plain English and correct the draft before it saves. event is a field a rule can test, so promo policy and signup policy stay separate.
The built-in sandbox has a promo scenario. Run it twice and watch the reuse signal fire on the second redemption, before you write any code at all."when the event is a promo redemption and more than 2 accounts are linked, deny"
What this does not do
It does not know whether a code is valid, expired or already spent according to your billing system. That is your data and your rule to enforce. This answers the one question your billing system cannot: whether the person redeeming has redeemed it already under another account.
OneTrial also does not do payment fraud or chargebacks, which is Stripe Radar's job and needs the transaction we deliberately never see. It does not do account takeover or credential stuffing either, because those are questions about a login rather than about whether someone is new.