Skip to main content
Pirehub can generate a Vietnamese bank-transfer QR payload and a self-contained SVG image. The QR is rendered on Pirehub infrastructure; bank account details, amount, and memo are not sent to an external QR image provider.

Integration flow

  1. Load the current bank directory from GET /api/v1/tools/bank-qr/banks.
  2. Let the payer select a bank and retain its bin, code, or shortName.
  3. Send the selected identifier and beneficiary account number to POST /api/v1/tools/bank-qr.
  4. Display data.qr.image.dataUrl or store data.qr.payload for another standards-compatible QR renderer.
  5. Display any entries in data.warnings, then ask the payer to verify the beneficiary in their banking app before confirming the transfer.

Authentication

Authenticate integrations with OAuth or a Pirehub API key. Generation requires bank-qr:generate; reading the directory requires bank-qr:banks. Send an API key in x-pirehub-api-key or a bearer header, and keep the credential on your server. Invalid credentials return 401; revoked, expired, or under-scoped credentials return 403. Administrator-issued API keys use the key’s per-minute and monthly request limits. Inspect X-ApiKey-* headers and honor Retry-After after a 429.

Load the bank directory

Use the directory instead of maintaining a bank list in application code. The response contains accepted identifiers, transfer-support metadata, and optional allowlisted logo URLs.
An abbreviated response looks like this:
The example is shortened to two entries. A real response returns the complete directory and a matching count. updatedAt identifies the directory snapshot, not the time of the client request. Cache the response according to its Cache-Control header. A bank logo is optional, so always provide a local fallback and do not treat an image-load failure as a directory failure. Logo URLs point to allowlisted bank-logo asset hosts. Rendering one directly causes the user’s browser to contact that host; cache or self-host permitted assets when your privacy requirements prohibit that request.
transferSupported is compatibility metadata. It does not prove that a beneficiary account exists or can currently receive a transfer.

Generate a QR code

bank is case-insensitive and may be the six-digit bin, code, or shortName returned by the directory. Keep accountNumber as a JSON string; converting it to a number can remove leading zeroes.

Request fields

Unknown fields are rejected, and the complete JSON request body must not exceed 4 KiB.

Static and dynamic QR codes

The optional memo can be included in either type.

Successful response

The SVG data URL above is truncated for readability. The API returns the complete image. data.transfer contains the normalized values actually encoded in the QR, so use it instead of redisplaying unprocessed request input. Assign the data URL to an image src. Do not decode the SVG and inject it into the page as HTML.

Memo normalization and warnings

The API folds Vietnamese diacritics to ASCII, replaces unsupported characters, collapses consecutive spaces, and limits the encoded memo to 25 characters. It returns MEMO_NORMALIZED when the encoded value differs from the submitted memo. LIMITED_TRANSFER_SUPPORT means the institution has limited bank-transfer QR compatibility metadata. Generation still succeeds, but you should test the QR with the intended banking apps before publishing it. Warnings are successful outcomes, not API errors. Handle them by code rather than parsing the human-readable message.

Server example

Failures and safe handling

Every JSON error includes data.requestId. Record that opaque value for support, but branch only on error.code.
QR generation does not validate the beneficiary account, encode or verify an account-holder name, move money, or confirm a transfer. The payer must verify the recipient and amount in their banking app. Payment confirmation requires a separate authenticated bank or payment-provider integration.
Avoid placing real account numbers or generated payloads in application logs, analytics, URLs, or long-lived browser storage. The generation response uses Cache-Control: no-store.

Next steps

Bank directory endpoint

Review the directory response and bank metadata schema.

Generate QR endpoint

Review the complete generation request and response schema.

Errors and retries

Handle failures safely and predictably.

Subscription-backed API keys

Paid self-service keys use shared owner credits and the plan’s per-second and concurrent-job limits. Successful results, including cache hits, consume the configured action cost; errors release the reservation. Video jobs settle at completion. Inspect X-ApiKey-Credit-* and X-ApiKey-RateLimit-*. An optional Idempotency-Key prevents repeated synchronous execution/debits; repeated operations return 409 rather than replaying a response. Job starts use requestId instead. See API plans and idempotency for costs, billing periods, headers, error codes and retry rules.