DEV Community: Nguyễn Hương

QR payment gateway with multi-channel balance alerts

Nguyễn Hương — Tue, 06 Oct 2026 04:55:12 +0000

When every bank-transfer order needs someone watching the banking app

For many online stores, accepting bank transfers is still a manual job. The customer sends the money, then a screenshot. The seller opens the banking app, scrolls through transactions, and only then confirms the order.
This approach has four weak spots:
• Slow: customers wait for confirmation, and orders stall outside business hours.
• Error-prone: several orders share the same amount, and customers mistype the transfer note or send too little.
• Risky: a screenshot does not prove the money actually reached the account.
• Hard to coordinate: sales, warehouse and accounting all need to know the money is in, but only the account holder can see the banking app.
PionPay's payment gateway solves this with one simple principle. Customers just scan. The moment the money lands, the balance alert is already where you work.

How does the PionPay payment gateway work?

Going from scan to confirmed order takes 5 steps, and none of them are manual:

A payment QR code is created for the order. It holds the receiving account, the amount and the transfer note for that order.
The customer scans it with their banking app and confirms. There is no account number or amount to type, so fewer mistakes.
The money arrives in the linked bank account. PionPay records the balance change instantly.
PionPay sends an alert to the channels you have set up: Telegram, Zalo, Google Sheets or a webhook on your online store.
The order is confirmed automatically as soon as the customer pays. The transaction is also categorized and recorded in your income and expense log.

PionPay connects withbanks, including VPBank, BIDV, ACB, TPBank and PGBank. All your accounts come together in a single dashboard.

Where do alerts go? Pick the channels that fit how you work
Everyone in a store needs to hear about incoming money in a different way. Owners want it on their phone, accountants need records, and the website needs a signal to update orders on its own. PionPay sends each balance change to the right channel for each need.

On the Business plan, the balance sharing feature lets several people see incoming payments without anyone being given access to the banking app.
For developers: receiving webhooks on your online store
If you run your own website or sales software, the webhook moves orders to "Paid" automatically. Each time the balance changes, PionPay sends an HTTP request to the URL you register. The example below uses Node.js (Express). Field names are for illustration only, so follow PionPay's integration documentation when you build it.

import express from "express";

const app = express();
app.use(express.json());

const processed = new Set(); // in production: a DB table with a unique key on the transaction ID

app.post("/webhooks/pionpay", async (req, res) => {
  // 1. Verify the sender as described in the integration guide
  if (!isFromPionPay(req)) return res.sendStatus(401);

  // 2. Illustrative field names
  const { transactionId, amount, description } = req.body;

  // 3. Process each transaction only once
  if (processed.has(transactionId)) return res.sendStatus(200);
  processed.add(transactionId);
  res.sendStatus(200); // respond right away, run business logic afterwards

  // 4. Match the order code in the transfer note (e.g. DH123456)
  const orderCode = description?.toUpperCase().match(/DH\d{6}/)?.[0];
  if (orderCode) await markOrderPaid(orderCode, amount, transactionId);
});

A few tips for the integration:
• Always verify the sender before updating an order. Do not trust every request that reaches your webhook URL.
• Check the amount against the order total, and handle underpayments and overpayments separately.
• Send transactions with no matching order code to a manual review queue. Never guess which order they belong to.
Get started with the PionPay payment gateway
Both plans include the payment gateway and Webhook/API:

Business: VND 50,000/month
1 bank account, balance sharing, payment gateway, Webhook/API
Individual: VND 99,000/month
1 account, unlimited transactions, payment gateway, Webhook/API

You can start accepting payments automatically in 4 steps:

Sign up for a PionPay account.
Link the bank account that receives payments.
Choose where to get alerts: Telegram, Zalo, Messenger, Google Sheets or webhook.
Create a QR code for each order and send it to your customer.

From then on, customers just scan and PionPay takes care of the rest. Sign up now at pionpay.vn, or message PionPay on Facebook

Xác thực OTP ngân hàng trên PionPay: kết nối mà không cần đưa mật khẩu

Nguyễn Hương — Wed, 30 Sep 2026 03:45:11 +0000

Khi kết nối một tài khoản ngân hàng với hệ thống thanh toán, thông tin đăng nhập luôn là điều được quan tâm nhất. PionPay chọn phương thức xác thực trực tiếp bằng OTP từ ngân hàng để bạn không phải giao tài khoản và mật khẩu ngân hàng cho bên thứ ba.

Xác thực OTP ngân hàng trên PionPay là gì?

Xác thực OTP ngân hàng là phương thức kết nối tài khoản trong đó bạn xác nhận bằng mã OTP (mật khẩu dùng một lần) do chính ngân hàng gửi tới, thay vì cung cấp tài khoản và mật khẩu đăng nhập. OTP có hiệu lực rất ngắn và chỉ dùng được một lần, nên là lớp xác thực an toàn cho thao tác kết nối.

Với cách này, bạn chủ động thực hiện bước xác thực, còn PionPay hạn chế tối đa việc tiếp nhận và lưu giữ thông tin đăng nhập ngân hàng của bạn trong quá trình kết nối.

Quy trình kết nối bằng OTP gồm những bước nào?

Quy trình kết nối đơn giản và do bạn tự thực hiện, gồm năm bước:

Chọn ngân hàng cần kết nối trong danh sách hỗ trợ.
Nhập các thông tin cần thiết theo yêu cầu để bắt đầu kết nối.
Nhận mã OTP do ngân hàng gửi tới số điện thoại/kênh xác thực của bạn.
Nhập OTP để xác thực ngay trên bước kết nối.
Hoàn tất kết nối, tài khoản sẵn sàng nhận thông báo biến động số dư.

Toàn bộ mã OTP do bạn nhận và nhập, không phải đọc hay gửi cho nhân viên nào. Đây là điểm cần nhớ để tránh nhầm với các chiêu lừa yêu cầu "đọc mã OTP".

Vì sao không phải đưa mật khẩu ngân hàng cho bên thứ ba lại quan trọng?

Không đưa mật khẩu và OTP cho bên thứ ba là nguyên tắc bảo mật cơ bản mà cả ngân hàng lẫn cơ quan chức năng liên tục khuyến cáo. Cơ quan công an khuyến cáo khách hàng tuyệt đối không cung cấp cho bất kỳ ai các thông tin dịch vụ ngân hàng gồm tài khoản đăng nhập, mật khẩu và mã OTP, ngay cả khi người yêu cầu tự xưng là nhân viên ngân hàng (Nguồn: cơ quan Công an, ANTV, 2025).

Ở cấp quy định, Thông tư 50/2024/TT-NHNN yêu cầu đơn vị cung cấp dịch vụ Online Banking phải hướng dẫn khách hàng bảo vệ OTP và nhận diện các tình huống lừa đảo, giả mạo (Nguồn: Thời báo Ngân hàng, 2025). Phương thức xác thực OTP trực tiếp từ ngân hàng của PionPay đi theo đúng tinh thần này: giảm số lượng thông tin nhạy cảm mà bạn phải chia sẻ khi kết nối.

PionPay bảo vệ thông tin đăng nhập của bạn thế nào?

PionPay được thiết kế để hạn chế tiếp xúc với thông tin đăng nhập ngân hàng của bạn, dựa trên các nguyên tắc sau:

Không yêu cầu mật khẩu ngân hàng: bạn xác thực bằng OTP do ngân hàng gửi, không phải cung cấp mật khẩu đăng nhập cho PionPay.
Không lưu mật khẩu: hệ thống không lưu giữ mật khẩu ngân hàng của bạn.
Không thao tác chuyển tiền: kết nối phục vụ nhận thông tin biến động số dư, không dùng để chuyển tiền trên tài khoản của bạn.
Dữ liệu được mã hóa khi lưu và khi truyền.
Tiêu chuẩn an toàn thông tin: PionPay đã đạt chứng chỉ ISO/IEC 27001:2022 (phạm vi phát triển, gia công và kinh doanh phần mềm).

Nói cách khác, bạn được chủ động hơn trong việc bảo vệ thông tin đăng nhập, còn thao tác kết nối vẫn đơn giản.

Kết nối ngân hàng an toàn hơn cùng PionPay

Xác thực bằng OTP giúp bạn kết nối ngân hàng đơn giản hơn trong thao tác và chủ động hơn trong việc bảo vệ thông tin đăng nhập. Vào PionPay để kết nối tài khoản và bắt đầu nhận thông báo biến động số dư, hoặc gọi hotline 0981.690.369 nếu cần hỗ trợ.

What Is a Webhook? A Practical Guide (Plus a Real-World Bank Transfer Use Case)

Nguyễn Hương — Wed, 30 Sep 2026 02:57:14 +0000

Have you ever written something like this?

js
setInterval(async () => {
  const res = await fetch('https://api.example.com/orders/123/status');
  const { status } = await res.json();
  if (status === 'paid') {
    // Finally!
  }
}, 5000);

Every 5 seconds you ask the server: "Anything new?" And 99% of the time the answer is "Nope." It wastes requests, burns resources, and is still slow.

Webhooks exist to solve exactly this problem. In this post we'll cover:

What a webhook is and how it works
Webhooks vs. polling
Building a webhook endpoint in Node.js (with signature verification)
Best practices for reliable, secure webhooks
A very practical use case: getting near-instant bank balance notifications with PionPay

1. What is a webhook?

A webhook is an HTTP callback. When an event happens in system A, system A proactively sends an HTTP request (usually a POST) to a URL you provided, carrying data about that event.

In short: instead of you asking over and over, the other system tells you when something happens.

Real-life analogy: You order something online.
Polling = walking to the front door every 10 minutes to check if the courier has arrived.
Webhook = leaving your phone number so the courier calls you when they're outside.

Webhooks are often called a "reverse API" or "push API", because the direction is flipped: instead of the client calling the server, the server calls the client.

2. How do webhooks work?

A webhook flow has four steps:

Register: You give the provider a public URL (an endpoint) to receive data.
Event happens: Someone pushes code, a payment succeeds, money lands in an account...
Deliver: The provider sends a POST request with a payload (usually JSON) to your URL.
Acknowledge: Your server returns a 2xx to confirm receipt. If it doesn't, most providers will retry later.

You use webhooks every day, maybe without noticing:

GitHub fires webhooks to trigger CI/CD on pushes and pull requests.
Stripe fires webhooks when a payment succeeds or is refunded.
Slack / Discord let you post messages into channels via incoming webhooks.
Bank notification services fire webhooks when an account balance changes — more on this at the end.

3. Polling vs. webhooks

Webhooks don't always fully replace polling. Many solid systems use both: webhooks for real-time events, plus a periodic reconciliation job (polling) to catch anything that slipped through.

4. Building a webhook endpoint in Node.js

Let's build a webhook receiver with Express. It will do the three things every production endpoint needs:

Verify the signature (make sure the request really came from the provider)
Be idempotent (never process the same event twice)
Respond fast, and do the heavy lifting later

Note: Header names, signing algorithms and payload shapes vary by provider. The code below uses the most common pattern: HMAC-SHA256 with an X-Signature header. For a real integration, follow your provider's docs.

bash
npm init -y
npm install express

js
// server.js
const express = require('express');
const crypto = require('crypto');

const app = express();
const WEBHOOK_SECRET = process.env.WEBHOOK_SECRET;
const processedEvents = new Set(); // Demo only: use a DB/Redis in production

// Compare signatures with timingSafeEqual to avoid timing attacks
function isValidSignature(rawBody, signature) {
  if (!signature) return false;
  const expected = crypto
    .createHmac('sha256', WEBHOOK_SECRET)
    .update(rawBody)
    .digest('hex');
  const a = Buffer.from(expected);
  const b = Buffer.from(signature);
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

// Use express.raw to keep the original body bytes — required for signing
app.post('/webhooks/demo', express.raw({ type: 'application/json' }), (req, res) => {
  // 1. Verify: did this really come from the provider?
  if (!isValidSignature(req.body, req.get('X-Signature'))) {
    return res.status(401).send('Invalid signature');
  }

  let event;
  try {
    event = JSON.parse(req.body.toString('utf8'));
  } catch {
    return res.status(400).send('Invalid JSON');
  }

  // 2. Idempotency: skip events we've already handled (providers may resend)
  if (processedEvents.has(event.id)) {
    return res.status(200).send('Already processed');
  }
  processedEvents.add(event.id);

  // 3. Acknowledge IMMEDIATELY, process later
  res.status(200).send('OK');

  setImmediate(() => handleEvent(event));
});

async function handleEvent(event) {
  // Update orders, send emails, post to Telegram...
  console.log(`Received event ${event.type}:`, event.data);
}

app.listen(3000, () => console.log('Webhook server listening on port 3000'));

Why express.raw() instead of express.json()? The HMAC signature is computed over the exact raw bytes of the body. If you let Express parse the JSON and then JSON.stringify it back, key order or whitespace may change and the signature will never match. This is one of the most common bugs in first-time webhook integrations.

Test it with curl

Start the server:

bash
WEBHOOK_SECRET=my_secret node server.js

In another terminal, simulate a provider sending a signed webhook:

bash
WEBHOOK_SECRET=my_secret
BODY='{"id":"evt_001","type":"order.paid","data":{"orderId":"DH123","amount":150000}}'
SIG=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$WEBHOOK_SECRET" | sed 's/^.* //')

curl -X POST http://localhost:3000/webhooks/demo \
  -H "Content-Type: application/json" \
  -H "X-Signature: $SIG" \
  -d "$BODY"

What you should see:

First request → OK, and the server logs Received event order.paid: { orderId: 'DH123', amount: 150000 }
Send the exact same request again → Already processed (idempotency works)
Change X-Signature to anything else → 401 Invalid signature
Exposing localhost for real providers

Providers can't reach your localhost. During development you can use:

ngrok: ngrok http 3000 gives you a public HTTPS URL that tunnels to your machine.
Cloudflare Tunnel (cloudflared): similar, and free.
webhook.site: just to inspect what a provider sends, before writing any code.

5. Webhook best practices

Receiving a request is easy. Making it reliable in production is where it gets interesting.

Security

Always use HTTPS for your webhook URL.
Always verify signatures (HMAC, tokens, or whatever your provider supports). Your webhook URL is public — anyone can send fake requests to it.
Compare signatures in constant time (crypto.timingSafeEqual), not with ===.
If the provider publishes its IP ranges, consider IP allowlisting as an extra layer.
For anything involving money: don't blindly trust the payload. Cross-check the amount and order ID against your own data before updating status.
Reliability
Return 2xx as fast as possible. Most providers time out after a few seconds. Push heavy work (calling other APIs, sending emails, multi-table writes) onto a queue (BullMQ, RabbitMQ, SQS...).
Design for idempotency. Webhooks are usually delivered at least once — the same event can arrive 2–3 times. Store the event ID (or transaction ID) in your DB with a UNIQUE constraint.
Don't rely on ordering. A later event may arrive first.
Run a periodic reconciliation job to catch missed events (server downtime, bad deploys...).

Observability

Log raw payloads (with sensitive data masked) for debugging.
Alert when the webhook failure rate spikes.

6. Real-world use case: bank balance notifications with PionPay

Now for the use case where webhooks really shine, especially in Vietnam: automatic bank transfer confirmation.

The problem

In Vietnam, bank transfers — especially via QR codes (VietQR) — are one of the most popular ways to pay, whether for e-commerce, online courses, SaaS subscriptions or wallet top-ups. Yet confirmation is often still manual:

The customer makes a transfer
The customer sends a screenshot of the receipt via chat
Staff open the banking app and search for the transaction
Staff update the order by hand

The result: customers wait, staff waste time, mistakes happen, and there's a real risk of fake transfer screenshots. And if someone orders at 2 AM... the order just sits there until morning.

The solution: balance change webhooks

PionPay connects to your bank accounts via Open API and notifies you whenever your balance changes — via Webhook/API for system integration, or via Telegram/Messenger if you just want alerts.

Here's what an automated payment confirmation flow looks like with webhooks:

No more combing through bank statements. No more waiting for screenshots. Orders get confirmed 24/7, even at 2 AM.

Why PionPay?

Fast: balance change notifications in about 2 seconds — no need to open a banking app or wait for an SMS.
Reliable: 99.99% uptime.
Multi-bank: supports 10+ Vietnamese banks including BIDV, ACB, TPBank and PGBank; manage multiple accounts from one dashboard.
Secure: connects via Open API, encrypts data, never stores passwords and has no access to your account — it only receives transaction notifications.
Multiple channels: Webhook/API for developers, Telegram/Messenger for operations teams.
Extras: QR payment code generation, automatic transaction categorization, daily/weekly/monthly revenue tracking. Get started in a few steps

Sign up at pionpay.vn.
Link your bank account via Open API.
Register your webhook URL (the endpoint from section 4) in the dashboard — or connect Telegram/Messenger if you only need alerts.
Write your handler: match the transfer reference to an order ID, check the amount, update the status.

Every best practice from section 5 applies here, and with money involved they matter even more: verify requests, stay idempotent on the transaction ID, and always cross-check the amount before confirming an order.

Ideas for what to build

E-commerce / landing pages: automatically mark orders as "Paid" when the money arrives.
Online courses: activate student accounts right after the transfer.
Wallet / account top-ups: credit balances automatically based on the transfer reference.
SaaS: renew subscriptions automatically.
Ops teams: post incoming payments to a Telegram group so the whole team can follow along.

7. Wrapping up

A webhook = another system calls your URL when an event happens, instead of you asking over and over (polling).
A good webhook endpoint needs HTTPS, signature verification, fast responses, idempotency, and a reconciliation fallback.
For bank-transfer payments in Vietnam, balance change webhooks let you confirm orders almost instantly, cut down on errors and block fake receipts.

If you're still confirming bank transfers by hand, give PionPay a try — you can integrate it with a single endpoint like the one above.

What's the worst webhook bug you've run into — missed events, duplicate processing, signature mismatches? Share it in the comments!

PionPay Officially Integrates ACB Bank API: Automated Transactions and Reconciliation for Businesses

Nguyễn Hương — Sat, 26 Sep 2026 03:04:05 +0000

Many businesses take bank transfer payments every day. For them, opening the banking app, checking each incoming transaction and matching it to an order takes a lot of time and invites mistakes. To solve this, PionPay has officially integrated the API of Asia Commercial Joint Stock Bank (ACB). Businesses with ACB accounts can now connect them directly to PionPay and manage all their transactions on one platform.

What is the ACB API integration on PionPay?

An API integration is a direct connection between the bank's system and PionPay. Once an ACB account is linked, its transaction data flows into PionPay automatically. The system then receives and processes each transaction based on the rules the business has set up.

In short: when money arrives in your ACB account, PionPay records and processes it for you. You don't have to keep watching your banking app or check payments by hand.

What businesses get from the ACB API integration

🏦 Direct connection to your ACB account

Link your ACB bank account to PionPay through the API. You connect once, and your transaction data keeps syncing to the system from then on.

💰 Automatic transaction tracking

PionPay receives every transaction on your ACB account and processes it based on your settings. Your operations team no longer needs to check every balance change.

🔄 Payment process automation

PionPay cuts down on manual steps such as confirming transfers, updating order statuses and matching transfer descriptions. You save time, make fewer mistakes and fulfill orders faster.

📊 Easier cash flow management and reconciliation

All transaction data is centralized in PionPay. You can monitor cash flow, look up transaction history and handle end-of-day or end-of-period reconciliation more easily.

An ACB-exclusive feature: virtual account (VA) creation

PionPay also supports creating virtual accounts (VA) on ACB.

Businesses often use virtual accounts to separate and identify incoming payments, for example by assigning one to each customer or each order. This makes it clearer who has paid and what each payment is for.

We'll cover how VA creation on ACB works in an upcoming post, so follow the PionPay blog to stay updated!

Who should use the ACB API integration on PionPay?

Businesses and online stores that receive payments to an ACB account
Companies with a high volume of bank transfers that need fast, accurate confirmation
Accounting teams that want a central tool for reconciliation and cash flow management
Businesses that want to automate payments and rely less on manual work
Connect ACB to PionPay today

If your business uses an ACB account and you want to automate transaction tracking and processing, contact PionPay for a consultation and help with setup.

🌐 Website: PionPay.vn
📞 Hotline: 0981.690.369

Create ACB Virtual Accounts (VA) with PionPay for Faster Cash-Flow Reconciliation

Nguyễn Hương — Sat, 26 Sep 2026 02:59:29 +0000

When many orders and payments flow into a single account, figuring out who paid and which order the money belongs to takes time. With PionPay, you can create Virtual Accounts (VA) on ACB to separate and manage incoming payments more clearly.

What is a VA on ACB?

A Virtual Account (VA) is an identifier account linked to a specific customer, order, or purpose, used to receive money. Each VA has its own unique identifier, so when funds arrive, the system immediately recognizes who the transaction belongs to. All collected funds still consolidate into your main account at ACB.

Example: Branch A → VA A; Branch B → VA B; Branch C → VA C.

How is a VA different from a shared receiving account?

A VA sorts incoming payments the moment money arrives, while a shared account forces you to reconcile manually afterward.

Criteria Shared account With VA
Identifying the payer Relies on transfer description; error-prone Based on a unique VA identifier
Reconciliation Manually checking each transaction Automatically categorized on arrival
Multiple orders at once Confusing, easy to miss items Each payment is clearly separated
Money management Centralized but hard to break down Centralized in the main account, still traceable by source

You also don't need to share your main account number with each customer.

How does PionPay help you create and manage VAs?

PionPay lets you create and manage ACB VAs directly within its platform, including:

Create VAs directly, without switching between multiple places.
Link each VA to a customer, order, or purpose according to how your business organizes its transactions.
Receive payments through individual VAs, making transactions easier to identify and reconcile.
How to add an ACB VA on PionPay
Go to the bank linking section and select "Virtual Account (VA)".
Enter a memorable name for the VA.
Confirm the OTP to create the VA.
Complete VA creation.

What should you keep in mind when using a VA?

A VA must be issued by a bank or an entity authorized by the bank, and used in line with the product's intended purpose. Opening and using payment accounts in Vietnam is governed by Circular 17/2024/TT-NHNN; the law prohibits identity impersonation and the buying, selling, renting, or lending of payment accounts (Source: FinanOne compilation, 2026). In this feature, VAs are created on ACB through PionPay's connection.

Frequently asked questions

Can I withdraw or transfer money out of a VA?
Typically, a VA is for receiving money only; funds are credited to your main account at ACB.

How many VAs can I create?
You can create multiple VAs by customer, order, or purpose; check PionPay or ACB's regulations for specific limits.

Does a VA help automate reconciliation?
Yes. Each transaction is tied to a unique VA, so payments are categorized as soon as money arrives.

Does money sent to a VA go to my main account?
Yes. The VA identifies the source of funds, while the money remains consolidated in your main account.

Start creating ACB VAs with PionPay

Go to PionPay to create an ACB VA, or call the hotline 0981.690.369 for advice on a setup that fits your business model.

The Hidden Costs of Integrating Directly with Bank APIs

Nguyễn Hương — Mon, 21 Sep 2026 11:01:05 +0000

"How hard can it be? The bank gives us an API. We call it. Done."

If you have ever said this in a planning meeting, this post is for you.

Integrating directly with a bank looks like the cheapest, most hands-on option: no middleman, no extra fees, full control. But the invoice never shows up as a line item. It shows up as missed deadlines, burned-out engineers, and a product roadmap that quietly stops moving.

Let's break down where the real costs hide.

1. The Time Cost: It's Never Just One Integration

Onboarding takes longer than coding

Before you write a single line of code, you typically need to:

Sign a commercial agreement and pass the bank's KYC/KYB process
Get your legal entity, business license, and use case approved
Request sandbox credentials (often via email, sometimes via a PDF form)
Complete security reviews, IP whitelisting, and certificate exchange

This can take weeks or months, and most of it is waiting, not building. Your engineers can't speed it up.

Every bank is a different snowflake

Once you're in, you discover there is no such thing as "the bank API". There are dozens of them, and they disagree on almost everything:

If your customers use more than one bank, you are not building one integration. You are building and maintaining N of them, each with its own quirks, its own docs (often outdated), and its own release cycle.

Testing is painful

Sandboxes are frequently incomplete. They don't simulate timeouts, duplicate callbacks, partial failures, or settlement delays. So you find out how the bank really behaves in production, with real money.

2. The Money Cost: Beyond the Bank's Fee Schedule

The bank may charge you little or nothing for API access. Your actual spend is elsewhere:

Engineering salaries. Multiple engineers for months is a real budget line, even if it never appears as "bank integration" in finance's spreadsheet.
Security and compliance. Certificate management, key rotation, audit logs, penetration testing, and possibly PCI or local regulatory requirements.
Infrastructure. Static IPs, VPN or dedicated connections, HSMs or secure key storage, monitoring and alerting.
Reconciliation tooling. Matching bank statements to your internal orders is a product in itself.
Failed and stuck transactions. Money in limbo means support tickets, manual refunds, and angry customers.
Opportunity cost. Every sprint spent on payment plumbing is a sprint not spent on features customers pay for.

A simple mental model:

Real cost = (engineer-months × loaded salary)
+ (compliance + infrastructure)
+ (ongoing maintenance × years)
+ (revenue lost from a delayed launch)

That last term is the one people forget, and it's often the biggest.

3. The People Cost: Your Best Engineers Stop Building Your Product

This is the most underestimated cost of all.

Payments are a specialty. To do them safely, someone on your team has to become an expert in:

Idempotency and exactly-once semantics
Webhook signature verification and replay protection
Settlement cycles, cut-off times, and holiday calendars
Reversals, chargebacks, and dispute flows
Regulatory changes that can land with only a few weeks' notice

Those people are now on call for payment incidents at 2 a.m. They are reading bank PDF specs instead of talking to users. If your company sells logistics, SaaS, e-commerce, or education, payments are not your core business, but they will start consuming a core-business amount of attention.

Here is a small example of code that is boring but has to be exactly right, and that you will have to write and operate yourself:

python
def handle_bank_callback(request):
    # 1. Verify the signature (each bank does this differently)
    if not verify_signature(request.headers, request.body):
        return Response(status=401)

    payload = parse(request.body)  # JSON? XML? encrypted?

    # 2. Idempotency: banks WILL send duplicates
    if already_processed(payload.transaction_id):
        return Response(status=200)

    # 3. Map bank-specific status to your internal state machine
    status = map_status(payload.bank_code, payload.status)

    # 4. Update order, ledger, and notify user, atomically
    with db.transaction():
        update_order(payload.order_ref, status)
        write_ledger_entry(payload)

    return Response(status=200)

Now multiply this by every bank, every payment method, and every edge case, and then maintain it forever.

4. The Ongoing Cost: Integration Is Not a Project, It's a Product

Shipping the integration is only day one. After that:

Banks deprecate endpoints, rotate certificates, and change fields
New regulations require new flows
Volumes grow and rate limits start to bite
Adding a new bank partner means starting from scratch
Documentation drifts from reality and nobody tells you

You've effectively created an internal payments team, whether you planned to or not.

So, When Does Going Direct Make Sense?

To be fair, direct integration is sometimes the right call:

Payments are your core business, or you're building a payment product yourself
You have very high volume, where the fee savings outweigh the engineering cost
You only need one or two banks, with stable, well-documented APIs
You have (or want to build) a dedicated payments engineering team

If that isn't you, consider the alternative.

The Alternative: Use an Abstraction Layer Like PionPay

Instead of wiring up every bank yourself, you can use a unified payment gateway to carry the heavy lifting. PionPay is one option worth considering in this category. The core value of this approach is:

One integration instead of N: you work against a single, consistent API instead of learning each bank
Normalized data models for transactions, statuses, and errors, so your callback handling code becomes much simpler
Managed security and compliance on the provider's side, reducing the burden of certificates, keys, and audits for your team
Faster go-live, often days or weeks instead of many months
A focused team that keeps building the product that sets you apart, instead of acting as payment infrastructure engineers

With that in place, the callback handler above can shrink to a thin layer: verify the signature once against a single standard, map one unified set of statuses, then update the order. The differences between banks are hidden behind the gateway.

You do pay a fee, but compare it honestly against the full cost model above, not just the bank's price list. Before choosing any provider, check the list of supported banks and payment methods, sandbox quality, SLAs, fee structure, and developer documentation.

A Quick Checklist Before You Decide

Ask your team:

How many banks or payment methods do we need in year one? In year three?
Who will maintain this integration, and who is on call for it?
How long can we afford to wait before launch?
What would our engineers build instead if they weren't doing this?
Do we know our real cost, including maintenance and opportunity cost?

If the answers make you uneasy, that unease is the hidden cost showing itself early.

Final Thoughts

Direct bank integration isn't wrong. It's just expensive in ways that don't appear on the quote. The hidden costs are time, money, and focus, and focus is the hardest to get back.

Before you commit, calculate the total cost of ownership, not just the sticker price. Then decide whether payments are something you want to build or something you'd rather use. If you lean toward the latter, take a look at PionPay.vn and run a small proof of concept to measure the real integration time for yourself.

Have you integrated directly with a bank? What surprised you most? Share your war stories in the comments. 👇

What Is an API?

Nguyễn Hương — Thu, 17 Sep 2026 05:07:48 +0000

An API (Application Programming Interface) is a defined way for two pieces of software to talk to each other. Instead of one program digging through another program's internal code or database, it sends a request in an agreed-upon format and gets back a predictable response. APIs are what let your app check the weather, charge a credit card, or confirm a bank transfer — without you having to build a weather station, a payment network, or a banking system yourself.

1. What does "API" actually mean?

Break the acronym down:

Application — a piece of software (a website, a mobile app, a service)
Programming — the code-level interaction, not a human interface
Interface — the point of contact between two systems

Put together: an API is the interface through which one application exposes its functionality so other programs can use it — without needing to know how it works internally.

A real-world analogy

Think of a restaurant.

You (the customer) don't walk into the kitchen and cook your own food.
You look at a menu (the API documentation) that tells you what's available and how to order it.
You give your order to a waiter (the API), who takes your request to the kitchen.
The kitchen (the internal system) prepares the food and hands it back to the waiter.
The waiter brings you the food (the API response) — you never see how the kitchen actually works.

That's exactly what happens when your code "calls an API": you send a request in a specific format, and you get back a specific response, without touching the internal logic of the other system.

2. How does an API actually work?

Most modern web APIs work over HTTP, the same protocol your browser uses to load web pages. The basic flow looks like this:

Your app sends a request to a specific URL (called an endpoint), often with some data attached.
The server processes the request — maybe it looks something up in a database, runs a calculation, or checks a bank balance.
The server sends back a response, usually in a structured format like JSON.
Your app reads the response and does something with it — displays it, stores it, triggers another action.

Example: a weather API request might look like this—

GET https://api.example.com/weather?city=Hanoi

And the response might look like this:

json
{
  "city": "Hanoi",
  "temperature": 31,
  "condition": "Partly cloudy"
}

You didn't need to know anything about weather satellites or forecasting models. You just asked a question in the agreed format and got a structured answer.

3. What are the common types of APIs?

REST APIs — the most common style for web APIs, using standard HTTP methods (GET, POST, PUT, DELETE) and usually returning JSON.
Webhooks — the reverse pattern: instead of you asking a server for data, the server pushes data to you the moment something happens (e.g. "a payment was just received").
GraphQL APIs — let the client specify exactly what data it needs in a single request, instead of hitting multiple fixed endpoints.
SDKs/Libraries — not APIs themselves, but code wrappers that make calling an API easier in a specific programming language.

4. Why do APIs matter so much in modern software?

Without APIs, every app would need to build everything from scratch: its own maps, its own payment processing, its own SMS sending, its own bank connections. APIs let teams specialize. One company builds a really good mapping service; everyone else just calls its API instead of reinventing it.

This is especially visible in fintech, where connecting directly to a bank's systems involves authentication flows, security requirements, and constant maintenance as banks update their systems. That's exactly the kind of problem APIs — and specifically webhooks — are built to solve, as the next example shows.

A concrete example: how a webhook API solves a real payment problem

To make all of this less abstract, let's walk through a real case: confirming that a bank transfer actually arrived.

If you're building a sales website in Vietnam, customers often pay by direct bank transfer instead of a card. The naive way to confirm payment is for someone on your team to open the bank app, check the balance, and manually match a transaction to an order. That doesn't scale, and it's exactly the kind of repetitive, error-prone task APIs exist to remove.

This is where PionPay.vn comes in, and it's a good illustration of the webhook pattern described above. Instead of your app repeatedly asking a bank "has this payment arrived yet?" (which would mean building and maintaining a direct integration with every bank's own API), PionPay.vn already maintains those bank connections for you. When a transfer lands in a linked account, PionPay's webhook sends a request straight to your system, the moment it happens.

In practice, your endpoint might receive something like this, example:

json
{
  "event": "transaction.received",
  "bank_account": "linked-account-id",
  "amount": 250000,
  "currency": "VND",
  "transaction_time": "2026-09-17T09:12:03+07:00",
  "reference": "ORDER-4821"
}

Your code doesn't need to know anything about how PionPay.vn talked to the bank, what authentication flow was involved, or how the balance change was detected. You just receive a predictable payload, match reference to an order in your database, and mark it as paid — the same "menu and waiter" pattern from earlier in this post, just applied to money instead of food.

This is also a nice example of why webhooks specifically (rather than a regular request/response API) make sense here: payment timing is unpredictable. A webhook lets the bank-integration layer notify you the instant something happens, instead of your app wastefully polling "any news?" every few seconds.

5. Common beginner questions about APIs

Is an API the same as a database? No. A database stores data. An API is a way to access functionality or data — sometimes that data comes from a database, but the API is the messenger, not the storage.

**Do I need to know a specific programming language to use an API? **No — APIs are language-agnostic. You can call the same API from Python, JavaScript, Go, or almost any language, as long as it can send HTTP requests.

What's an API key, and why do I need one? An API key is a unique identifier that tells the server who's making the request. It's used for authentication (proving you're allowed to use the API) and often for rate-limiting (making sure one user doesn't overload the service).

What's the difference between an API and a webhook? With a normal API, your app has to ask ("is there new data?"). With a webhook, the other system tells you the moment something happens, without you having to ask repeatedly. Webhooks are especially common for real-time events like payment confirmations, form submissions, or status updates.

PionPay: Skip Individual Bank API Integrations — Just Hook into PionPay’s Webhook

Nguyễn Hương — Wed, 16 Sep 2026 11:20:37 +0000

If you’re a developer maintaining an e-commerce platform or a payment system in Vietnam, building direct API integrations with multiple banks is slow, resource-draining, and a endless maintenance burden. PionPay has already built and maintained that integration layer with various banks across Vietnam. All you need to do is attach PionPay’s webhook to your existing payment flow and start receiving real-time transfer confirmations — no need to connect to each bank's API individually.

Pricing: 99,000 VND/month per linked bank account.
Website: pionpay.vn · Fanpage: facebook.com/pionpay · Hotline: 0981.690.369

We are currently opening early access for developers to integrate, stress-test, and share feedback before our broader rollout.

Contact our fanpage to claim a free trial package!

1. The Problem: Direct Bank API Integration is an "Engineering Tax" for Every Dev Team

If you’ve ever tried connecting a sales system directly to a Vietnamese bank’s API, you know it’s not a weekend project. Every bank comes with its own authentication flows, quirks, and incomplete documentation. Multiply that by the number of banks your customers actually use, and you’ll end up wasting:

Real engineering hours on integrations — work that has nothing to do with your core product.
Continuous maintenance every time a bank changes something on their end.
Extra infrastructure just to poll or listen for balance f luctuations reliably.

2. What PionPay Actually Does

PionPay takes care of the integration work across multiple Vietnamese banks for you. Instead of connecting to each bank individually, you only need to connect to a single webhook.
Here’s how the workflow looks:

You link a bank account with PionPay (via the PionPay dashboard).
PionPay monitors balance fluctuations for that account via direct bank API connections — no screen scraping involved.
When money arrives, PionPay instantly detects and verifies the transaction.
PionPay sends a confirmation payload to your system via webhook in rea l-time.

On your side, integration is as simple as: receiving the webhook payload, matching it with the order, and marking it as paid. That’s it. No dealing with bank authentication flows, no polling logic, and zero maintenance per bank.

3. Where This Webhook Fits in Your Tech Stack

PionPay is designed to sit alongside your existing tools without replacing your current stack:

Website / POS
Telegram
Zalo (Bots & Zalo OA)
Lark
Google Sheets

For most dev teams, the primary integration point is simply: Webhook -> Your Order/Payment System. Other channels (Telegram, Zalo, Sheets) are optional add-ons if you want notifications dispatched elsewhere.

**Pricing: Per Linked Account, Not Per Transaction

This is an important detail when scoping your integration:
99,000 VND/month per linked bank account.**

This means your cost scales with the number of bank accounts you need PionPay to monitor — not with transaction volume. If your business collects payments into a single account, that’s one fixed line item. If you collect through multiple accounts (e.g., by branch or business unit), each linked account is billed separately.

Full pricing details: pionpay.vn

4. How to Start Testing

Visit pionpay.vn to register and get your API/webhook access keys.
Link a test bank account (or a real account with low risk during trial).
Point the webhook to a test endpoint and confirm you’re receiving valid payloads.
Hook it into a sample order-matching workflow.
Share your feedback in the comments below, or reach out via our fanpage/hotline above.

5. Frequently Asked Questions

Do I need to integrate with each bank individually?
No — that’s the main purpose of PionPay. PionPay handles and maintains those integrations; you only consume a single webhook.
Is the pricing based on transaction volume?
No. It is a flat fee of 99,000 VND/month per linked bank account, regardless of how many transactions process through it.
Is banking data processed securely?
PionPay has achieved ISO/IEC 27001:2022 certification for Information Security Management Systems.

PionPay: Không cần tự kết nối API từng ngân hàng — Chỉ cần gắn webhook của PionPay

Nguyễn Hương — Wed, 16 Sep 2026 11:11:39 +0000

Nếu bạn là developer đang duy trì một website bán hàng hoặc hệ thống thanh toán tại Việt Nam, việc tự kết nối trực tiếp với API của từng ngân hàng vừa chậm, vừa tốn nguồn lực, vừa là thứ bạn phải bảo trì mãi mãi. PionPay đã xây và duy trì sẵn lớp tích hợp đó với nhiều ngân hàng tại Việt Nam. Bạn chỉ cần gắn webhook của PionPay vào luồng thanh toán hiện có và bắt đầu nhận xác nhận chuyển khoản real-time — không cần tự đi kết nối API với từng ngân hàng.

Chi phí: 99.000đ/tháng cho mỗi tài khoản ngân hàng liên kết.

Website: pionpay.vn · Fanpage: facebook.com/pionpay · Hotline: 0981.690.369

Chúng tôi đang mở để developer tích hợp, stress-test và góp ý trước khi ra mắt rộng rãi hơn.

Liên hệ fanpage để được tặng gói trải nghiệm!

1. Vấn đề: tự kết nối API ngân hàng là một "khoản thuế" cho mọi team dev

Nếu bạn từng thử kết nối trực tiếp một hệ thống bán hàng với API của ngân hàng Việt Nam, bạn sẽ hiểu đó không phải việc làm trong một cuối tuần. Mỗi ngân hàng có luồng xác thực riêng, có những điểm khó chịu riêng, tài liệu thì thiếu chỗ này chỗ kia. Nhân số đó lên với số lượng ngân hàng khách hàng của bạn thực sự dùng, và bạn sẽ tốn:

Thời gian engineering thật sự cho việc tích hợp — thứ chẳng liên quan gì đến sản phẩm cốt lõi của bạn
Bảo trì liên tục mỗi khi ngân hàng thay đổi gì đó phía họ
Hạ tầng thêm chỉ để poll hoặc lắng nghe biến động số dư một cách đáng tin cậy

2. PionPay thực sự làm gì

PionPay đã làm sẵn công việc tích hợp với nhiều ngân hàng tại Việt Nam. Thay vì bạn tự kết nối với từng ngân hàng, bạn chỉ cần kết nối với một webhook duy nhất.

Quy trình như sau:

Bạn liên kết một tài khoản ngân hàng với PionPay (qua dashboard của PionPay).
PionPay theo dõi biến động số dư của tài khoản đó thông qua kết nối API ngân hàng trực tiếp — không phải scraping màn hình.
Khi có tiền về, PionPay phát hiện và xác nhận giao dịch.
PionPay gửi xác nhận đến hệ thống của bạn qua webhook, theo thời gian thực.

Về phía bạn, công việc tích hợp chỉ là: nhận payload từ webhook, đối chiếu với đơn hàng, đánh dấu đã thanh toán. Vậy là xong. Không cần xử lý luồng xác thực ngân hàng, không cần logic polling, không phải bảo trì riêng cho từng ngân hàng.

3. Webhook này nằm ở đâu trong stack của bạn

PionPay được thiết kế để nằm cạnh những công cụ bạn đang dùng, không thay thế stack hiện có:

Website / POS
Telegram
Zalo (Bot và Zalo OA)
Lark
Google Sheets

Với hầu hết team dev, điểm tích hợp quan trọng nhất đơn giản là: webhook → hệ thống đơn hàng/thanh toán của bạn. Những kênh còn lại (Telegram, Zalo, Sheets) chỉ là tùy chọn nếu bạn muốn thông báo được đẩy thêm đến nơi khác.

Chi phí: tính theo số tài khoản liên kết, không tính theo giao dịch

Đây là chi tiết cần nói rõ vì nó ảnh hưởng đến cách bạn scope việc tích hợp:

99.000đ/tháng cho mỗi tài khoản ngân hàng liên kết.

Nghĩa là chi phí tăng theo số lượng tài khoản ngân hàng bạn cần PionPay theo dõi — không tăng theo số lượng giao dịch. Nếu doanh nghiệp bạn thu tiền vào một tài khoản duy nhất, đó là một dòng chi phí. Nếu bạn thu tiền qua nhiều tài khoản (VD theo chi nhánh, theo đơn vị kinh doanh), mỗi tài khoản liên kết sẽ được tính riêng.

Chi tiết bảng giá: pionpay.vn

4. Cách bắt đầu test

Truy cập pionpay.vn để đăng ký và lấy API/webhook access.
Liên kết một tài khoản ngân hàng test (hoặc tài khoản thật với mức rủi ro giới hạn trong lúc thử).
Trỏ webhook đến một endpoint test và xác nhận bạn nhận payload đúng.
Gắn vào một luồng đối chiếu đơn hàng mẫu.
Chia sẻ kết quả ở phần bình luận bên dưới, hoặc liên hệ qua fanpage/hotline ở trên.

5. Một số câu hỏi bạn có thể đang thắc mắc

Tôi có cần tự tích hợp với từng ngân hàng không?
Không — đó chính là mục đích của PionPay. PionPay duy trì các tích hợp đó; bạn chỉ cần tiêu thụ một webhook duy nhất.
Chi phí có tính theo số lượng giao dịch không?
Không. Là 99.000đ/tháng cho mỗi tài khoản ngân hàng liên kết, bất kể có bao nhiêu giao dịch chạy qua tài khoản đó.
Dữ liệu ngân hàng có được xử lý an toàn không?
PionPay đã đạt chứng chỉ ISO/IEC 27001:2022, về hệ thống quản lý an toàn thông tin.