Fraud and duplicate prevention

Gift cards are worth real money, so guard against accidental duplicates and against orders for the wrong person.

There is no server-side idempotency

Spendstream does not currently detect a repeated request. If your system sends the same order twice, it can be treated as two orders and issue two cards. You must prevent duplicates on your side.

⚠️ Warning: Spendstream rejects a repeat visit to an already paid order, but a narrow timing overlap between the browser return and the payment provider’s notification is still being hardened, so a duplicate cannot be ruled out. Never make issuance depend on a page load, and tell your customers not to refresh.

What to do on your side

• Create your own order record before you call Spendstream, and mark it as sent once you have.
• Allow only one request in flight for each order.
• Do not retry an order automatically after an unclear result. Read the transaction first to see whether the card was issued.
• Deduplicate inbound webhooks on the transaction or user identifier plus status, because there is no event identifier.
• Make your success page read only. It should display the result but never trigger issuance.
• Keep the Spendstream transaction identifier and your own order identifier together.

Validate before you act

• Validate the user. An unknown user_id sent to paymentLink is created automatically with blank details, so a typing error creates a new user. Check the user exists on your side first.
• Validate the balance. On the prepaid model, check checkPBalance before you place an order. See Prepaid balance management.
• Validate the reward. Confirm the user who will receive a reward is the right person before you allocate it.

Duplicate users

Calling addNewUser with a UID that already exists returns HTTP 200 with a body response of 400 and the message “User already exists with UID”, and no token. Read the body, then look the user up with getUsersList using the UID.

Related pages

• Reconciliation
• Common implementation mistakes