API Credential Security: The Gap Most Gift Card Resellers Miss

Picture opening your FazerCards balance on a Monday morning and finding it far lower than you left it on Friday. You placed no orders over the weekend, but someone found your API key in a GitHub commit from three months ago, wrote a short script, and spent the weekend buying gift card codes through your account. No hacking skill is needed for this, only a copy of a string left somewhere it could be read. Anyone running automated gift card fulfillment carries this risk, and it is easy to overlook until it becomes real.

Why gift card API credentials are high-value targets

Most API credentials gate an action with a delayed financial impact: a database write, a campaign send, a file upload. A gift card wholesale API key is different. It gates instant, automated purchasing that completes in seconds — funds leave your balance immediately, and codes deliver to whoever made the request. There is no shipping address, no identity check, no two-business-day hold that gives you time to intervene.

Resellers running automated stores and bots are especially exposed. The hands-off property that makes automation valuable also means an attacker's script runs just as smoothly as your own fulfillment code. A compromised key on an unmanned pipeline can drain a balance entirely before the owner notices.

Symptom: Unexpected balance drops or orders you didn't place

Cause: A leaked API key is being used by an external actor to place orders through your account.

Verification: Page through GET /orders (it takes only page and limit, so filter by date on your side) and look at when each recent order was created. Flag orders placed at unusual hours, for product categories you don't typically carry, or in quantities well above your normal per-order size. Cross-reference with your payment gateway — if your store processed no sales in a window where FazerCards shows completed orders, those orders are unauthorized. Also open Sign-in history in your panel Profile: a login you do not recognize means the password needs changing too, because the key is shown in the Profile.

Symptom: Webhook events that fail your signature check

Cause: Someone is probing or replaying requests to your webhook endpoint. Because webhook endpoints must be publicly reachable, they are actively scanned by automated tooling.

Verification: Every genuine FazerCards webhook carries X-Webhook-Signature: the value is "sha256=" followed by the hex HMAC-SHA256 of the raw request body, computed with your webhook secret. If your handler skips that check, it accepts any POST with matching JSON structure. Review your webhook handler now — a missing or incomplete signature check is easy to overlook, because everything still appears to work.

Symptom: Elevated API error rates you didn't generate

Cause: A leaked key is being used by a script that calls the API at high frequency. Rate limits are counted per key, so someone else's traffic uses up your quota.

Verification: If your application is not under unusual load but you start getting HTTP 429 responses, treat it as a credential-compromise signal until you can rule it out.

The four most common exposure paths

Understanding where keys leak is half the fix:

Source code commits — Hardcoded keys committed to a repository, including private repos that later become public, become permanent in git history. Deleting the line does not rewrite history: every earlier commit and clone still carries the value, so the key itself has to be replaced.
Environment files in version control — A .env file checked in by accident, even once and then removed in a later commit, lives in the commit log forever. Automated secret scanners index GitHub continuously.
Server and application logs — Code that logs the full request object, including headers, will log the X-Api-Key header. If those logs flow to a third-party aggregator, your key flows with them.
Client-side bundles — A server-side key accidentally imported into a file bundled for the browser is accessible to anyone who opens the browser console.

Secure storage practices

A solid credential baseline for any deployment:

Keep your X-Api-Key value and webhook secret in environment variables, never in source code or committed config files.
In production, store them in a dedicated secrets manager — AWS Secrets Manager, HashiCorp Vault, Doppler, or equivalent — so the key is never written to disk on the application server.
Configure your application logger to redact the X-Api-Key and X-Webhook-Signature headers from output. Most logging frameworks let you redact specific headers.
Regularly scan your repositories with a secrets-detection tool. Many CI providers include one; GitHub secret scanning is free on public repos and a paid add-on for private ones.
Treat the webhook secret with the same care as the API key — anyone who holds it can craft requests your fulfillment handler will accept as genuine.
Protect your panel login with a strong, unique password. The API key is shown in your panel Profile, so anyone who gets into the panel can copy it. Changing the password ends all sessions but does not change the key.
Keep on your balance roughly what you expect to spend soon instead of a large reserve. Your balance is the most a leaked key can spend.

The FazerCards API documentation covers authentication in full; the cookbook shows how to pass the key safely through environment variables in both Node.js and Python examples.

Replacing your API key: when and how

Replace your API key when any of the following occur: a team member with key access leaves; a repository containing the key becomes public, even briefly; a third-party service you passed the key to is breached; or you notice any unexplained order activity.

Each FazerCards account has one API key, shown in your panel Profile, and it does not expire while your subscription is active. There is no self-service rotation: open a support ticket and ask for the API key to be replaced. The old key stops working the moment the new one is issued, so there is no overlap period. Plan for that: if you are replacing the key as a precaution, pause order placement first, and as soon as the new key appears in your Profile, update it in your secrets manager, deploy and verify it with one authenticated call. Calls made with the old key get a 401 and place no order, so they can be retried once the new key is live.

Two other credentials have their own controls. You can regenerate the webhook secret yourself in the webhook settings of your panel or through the API; the old secret stops working immediately, so update your handler at the same time. If you connected an AI client through MCP, its link carries a separate token that replacing the API key does not affect, so reissue or revoke it in your Profile as well.

Webhook endpoint hardening

Your webhook endpoint is a public URL — anyone can POST to it. Signature verification is therefore not optional hygiene but the primary security layer for your fulfillment logic. See the FazerCards webhooks documentation for the full event schema.

Additional practices beyond signature checking:

Accept only POST requests on the webhook route; return 405 for any other method.
Log every incoming webhook: event type, order ID, and whether the signature passed or failed. This creates a forensic record if you need to audit fulfillment against payments later.
On a failed signature, return HTTP 401 and generate an internal alert. FazerCards retries failed deliveries after 1, 5, and 30 minutes using the same event ID — if retries are consistently failing signature checks, the webhook secret in your application may differ from the one registered on the platform.
Store processed event IDs and ignore repeats. Retries and replayed requests carry the same event ID, and a replayed request also carries a valid signature, so the signature check alone will not catch it.
After a completed webhook, fetch the full order response with GET /orders/:orderId to retrieve delivery codes. The webhook body carries only the order ID, type, status, and previous status — codes are not included.

Implementation checklist

Move your X-Api-Key value and webhook secret into environment variables or a secrets manager if they are not already there.
Run a secrets scan against your git history (tools: trufflehog, git-secrets, or GitHub secret scanning).
Confirm your webhook handler verifies X-Webhook-Signature on every request and returns HTTP 401 on a mismatch.
Configure your application logger to filter the X-Api-Key header from output.
Document who has access to the production API key and have the key replaced when that set changes.
Add order monitoring: FazerCards sends an order.created webhook for every new order, so compare each one with your own records and alert on any order your system did not place.
Keep on your balance roughly what you expect to spend soon, and use a strong, unique password for your panel login.

For the order reliability layer that sits on top of this security baseline — idempotency keys, retry logic, and status polling — see the guide to fault-tolerant orders.

FAQ

What happens to my balance if my API key is compromised?

Orders placed with a leaked key are real orders charged to your balance, and under the FazerCards terms you are responsible for activity under your account and API keys. So speed is what matters: the key stays valid until it is replaced, so contact FazerCards support immediately, ask for the API key to be replaced, and include the order IDs in question and when you believe the leak happened. If the panel may be affected too, change your password as well.

Can I restrict which IPs are allowed to use my API key?

No. FazerCards has no IP allowlist for API keys, so a copied key works from any address until it is replaced. That makes the habits in this guide the real protection: keep the key on your server, out of version control and logs, and keep your balance close to what you expect to spend soon.

How is a webhook secret different from an API key?

The API key authenticates outbound requests your code makes to FazerCards. The webhook secret is used to verify that inbound requests FazerCards sends to your server are genuine — it signs the event payload so you can confirm the request came from FazerCards and was not modified in transit. Store and handle both the same way: in environment variables or a secrets manager, never logged. If one leaks, replace it: you regenerate the webhook secret yourself, while the API key is replaced through support.

Where can I try this setup before going to production?

There is no sandbox: trial accounts run on the production API and trial orders are real orders charged to your balance. The free 5-day Gold trial gives you full API access across the entire catalog with no card required. Use it to place a few small real orders, verify your signature-checking code against real webhook events, and confirm your logger does not leak credentials — before you expose the integration to production traffic.