Common implementation mistakes

Mistake

What to do instead

Checking only the HTTP status

Most endpoints return HTTP 200. Read the response field in the body.

Hard-coding brand availability

Read the catalogue each time, because brands and offers change.

Treating affiliate transactions as instantly final

Wait until the transaction is confirmed. See Reconciliation.

Assuming a customer returning to your site means payment succeeded

Confirm through the TRANSACTION_UPDATED webhook or by reading the transaction.

Not storing Spendstream identifiers

Store the transaction identifier with your own order reference.

Not processing webhooks idempotently

There is no event identifier, so deduplicate on the transaction or user identifier plus status.

Exposing credentials client-side

Keep keys, secrets and token generation on your server.

Not checking the prepaid balance before gift card orders

Read checkPBalance first, where you use the prepaid model.

Fetching a token for every request

Cache the token. getToken is limited to five requests per minute.

Sending a brand identifier as promo_id

Send the promotion-id from getPromotionsList.

Relying on the success page to be safe to reload

A repeat visit to a paid order is rejected, but a narrow timing overlap is still being hardened. Keep your own duplicate protection. Gift card API requests have no server-side idempotency.

Relying on webhooks alone

There is no retry, so reconcile with getTransactionsList.

Trusting the webhook body because the signature is valid

The signature does not cover the body. Verify important data by reading the transaction.