Transaction verification

Save the purchase reference first

Generate and persist a unique reference before sending a purchase request. Use that same reference when checking the result. For example, a purchase with SMB202609160001 is retrieved at GET /transactions/SMB202609160001.

Do not replace the reference after a timeout. A new reference represents a new purchase, which can lead to duplicate charges.

Query the transaction

Send a server-side GET request with your secret key. The transaction lookup endpoint returns the transaction belonging to the authenticated account.

// Server-side Node.js 22+.
async function verifyTransaction(reference) {
  const response = await fetch(
    `https://api.strongmb.ng/v1/transactions/${encodeURIComponent(reference)}`,
    {
      headers: {
        Authorization: `Bearer ${process.env.STRONGMB_API_KEY}`,
        Accept: "application/json"
      },
      signal: AbortSignal.timeout(30000)
    }
  );
  const result = await response.json();
  if (!response.ok || !result.status) {
    throw new Error(result.metadata?.code || "Verification failed");
  }
  const transaction = result.data.transaction;
  if (!transaction || transaction.reference !== reference) {
    throw new Error("Transaction reference mismatch");
  }
  return transaction;
}
verifyTransaction("SMB202609160001")
  .then(transaction => console.log(transaction.status))
  .catch(console.error);

Read the right status field

Handle every outcome

Check the recipient, service and expected debit amount against your saved order. The amount debited can differ from face value when pricing or discounts apply. Use decimal-safe arithmetic.

Treat unknown outcomes carefully

If the lookup times out or returns not found while a purchase may still be in flight, keep the order unresolved. Retry verification with bounded backoff or investigate through recent history. Do not automatically submit a new purchase because one lookup failed.

Use verification with webhooks

When a webhook arrives, verify its reference using this same endpoint before updating the order. Keep order updates idempotent in your database so repeated processing does not fulfill twice.

Refund records

When a purchase returns data.status: failed, Strongmb has immediately issued the refund to your Strongmb wallet. A later GET /transactions/{reference} lookup may return data.transaction.status: refund. This means the purchase failed and was refunded; it is not a pending refund or a successful purchase. Strongmb sends the refund notification as transaction.refunded.

Do not wait for the refund webhook to interpret an authenticated failed purchase response as refunded, and do not issue another Strongmb wallet refund. Keep your own customer ledger consistent and apply each adjustment only once. This applies to a confirmed transaction status, not a validation error, timeout or processing response.

A failed purchase and its refund are separate records. The purchase has direction: debit and status: failed; the refund has direction: credit and status: refund. They share the original reference but have different transaction UUIDs. Use UUIDs to distinguish entries and the reference to associate them with your order.

Do not treat a refund credit as purchase fulfillment or refund it again. The related webhook event is transaction.refunded. See refund event handling.