免费二维码生成器 — 无需注册

创建适合您需要的银行标准的付款代码

从一处生成 VietQR、PromptPay、Pix、UPI、EPC、PayNow、Swiss QR-bill、SPAYD、PAY by square、HUB-3、NBS IPS 和 UPN 的支付负载。

  • 12 种市场特定格式
  • 收件人和金额验证
  • 不存储任何付款凭据

选择您客户的银行应用程序理解的付款代码

支付二维码不是一种通用格式。选择收款银行和付款人市场使用的标准,然后在兼容的银行应用程序中验证收款人和金额。

越南QR码

输入 NAPAS 成员银行 BIN、接收帐户、可选的 VND 金额和转账消息,为 NAPAS 247 创建 VietQR 有效负载。

即时支付二维码

使用注册的手机号码、国家或税务 ID 或受支持的电子钱包 ID 创建 Thai PromptPay QR,并可选择固定泰铢金额。

像素二维码

从电子邮件、电话、CPF、CNPJ 或 EVP 密钥生成巴西 Pix BR 代码,并带有可选的 BRL 金额、txid 和说明。

UPI二维码

将 UPI ID 转换为扫描支付二维码,其中包含收款人姓名和可选的 INR 金额、备注以及印度支持的 UPI 应用程序的参考。

EPC 二维码/GiroCode

以兼容的欧洲银行应用程序使用的 EPC QR 格式准备受益人、IBAN、可选 BIC、欧元金额、用途和参考。

PayNow二维码

从注册的新加坡移动代理或公司 UEN 生成与 PayNow 兼容的 SGQR 有效负载,并带有可选的 SGD 金额和参考。

瑞士二维码

使用瑞士 IBAN 或 QR-IBAN、结构化债权人地址和兼容参考,通过瑞士交叉货币生成瑞士法郎或欧元的固定瑞士 QR 代码有效负载。

SPAYD QR 平台

根据 IBAN、金额、货币、变量符号、到期日和消息构建捷克语短付款描述符。

PAY by square

以“PAY by square”格式对斯洛伐克欧元付款进行编码,其中包含受益人、IBAN、金额、变量符号、到期日和注释。

HUB-3 PDF417条码

生成基于官方线路的克罗地亚 HUB-3 支付负载,并将其呈现为 PDF417(而非 QR),其中包含欧元金额、HR IBAN、型号、参考和用途。

国家统计局IPS二维码

生成塞尔维亚 IPS QR 有效负载,其中包含 18 位帐户、收件人、RSD 金额、付款代码、用途、付款人和可选参考。

UPN二维码

生成包含欧元金额、收件人、IBAN、SI 或 RF 参考、目的代码、描述和到期日的 UPN QR 有效负载。

了解更多

没有任何银行应用程序都接受单一的二维码格式

方形条形码可以包含网址、纯文本或结构化银行有效负载。支付应用程序仅识别它们支持的结构。从国家/地区和接收帐户开始,而不是从代码的视觉外观开始。

首先选择正确的市场

国家/地区页面解释了每种格式所需的帐户标识符、货币和银行应用程序。

减少手动输入

兼容的应用程序会读取收件人、金额和参考信息,而不是要求付款人复制冗长的帐户详细信息。

保持付款人的批准

代码准备转账;付款人仍必须验证受益人并授权其银行或钱包付款。

二维码内

该生成器做什么和不做什么

生成器验证可见字段并以选定的市场格式对其进行编码。它不开设账户、注册支付代理、检查账户所有权或确认结算。

有效负载取决于支付方案

某些格式使用 EMVCo 标签长度值数据,某些格式使用行或键值对,而 PAY by square 使用压缩的二进制数据。

条形码类型也可以不同

大多数条目使用 QR,但克罗地亚的 HUB-3 使用 PDF417。瑞士 QR 法案需要瑞士十字,而 UPN 则修复 QR 版本和字符编码。

校验和仅保护有效负载结构

CRC 或其他校验和可以检测损坏的数据。它不能证明受益人是值得信赖的或钱已经到达。

银行应用程序仍然是最终决定权

支持因银行和应用程序版本而异。始终使用真实付款人将使用的相同应用程序和帐户类型进行测试。

典型的支付代码流程

国家、接收标识符、金额和参考号 — 具有所需验证的特定于市场的支付负载 — 兼容的应用程序会显示付款信息,供付款人验证和授权。

发布前检查

  • 选择收款帐户使用的标准,而不仅仅是付款人的位置。
  • 在生成之前验证帐户、代理、IBAN 和参考的每一位数字。
  • 使用正式支持所选标准的银行应用程序进行扫描。
  • 在批准付款之前比较显示的受益人和金额。
  • 测试最终的打印尺寸、对比度和周围的净空间。
  • 从接收帐户确认收据而不是屏幕截图。

发布支付代码的安全工作流程

语法上有效的代码仍然可能包含错误的帐户或不受特定应用程序的支持。

从官方银行详细信息开始

从银行或支付提供商帐户而不是从旧标志或聊天消息中复制接收标识符。

生成小额测试付款

在将代码放在发票、柜台或包装上之前,请检查已解析的受益人和实际收据。

显示附近人类可读的详细信息

在代码旁边打印收件人、货币和预期金额或发票参考号,以便付款人进行比较。

保护物理显示器

检查公共代码以查找替换贴纸,并在基础帐户发生更改时重新生成它们。

特点

特点

特定于方案的验证

针对所选付款标准检查帐户标识符、金额格式、参考和字段长度。

本地生成

支付负载和条形码在浏览器中创建;生成器不转移资金或注册帐户。

PNG 和 SVG 导出

下载日常使用的光栅图像或用于发票和高质量打印的可扩展矢量。

受保护的固定格式

规定渲染的标准禁用不兼容的颜色、徽标、形状和纠错控制。

可选的支付上下文

如果计划允许,请准备金额、参考资料、到期日或消息以减少付款人输入。

验证仍然可见

该工作流程提醒付款人在兼容的银行应用程序中比较受益人和金额。

优点 & 局限性

优点

  • 多种开放且可互操作的支付格式的起点。
  • 减少长帐户标识符和参考的输入。
  • 可以在所选方案允许的情况下准备一定的金额。
  • 在浏览器本地创建有效负载。

局限性

  • 对于不受支持的银行应用程序来说,一个市场的代码可能是纯文本。
  • 生成者无法验证帐户所有权或付款状态。
  • 商户回调和对账需要银行或支付提供商。
  • 物理代码可以被替换,因此付款人必须验证受益人。

付款代码如何运作

从付款详细信息到银行应用程序确认屏幕

方形条形码可以包含网址、纯文本或结构化银行有效负载。支付应用程序仅识别它们支持的结构。从国家/地区和接收帐户开始,而不是从代码的视觉外观开始。

选择付款标准

将格式与收款银行帐户和付款人将使用的应用程序相匹配。

输入并验证付款详细信息

添加该方案所需的收件人标识符、金额和参考信息。

扫描、比较并发布

在共享代码之前,在兼容的应用程序中进行测试并比较受益人和金额。

使用案例

使用案例

发票

准备帐户、金额和参考数据,以便客户无需重新输入。

零售柜台

显示与本地客户使用的国内应用程序匹配的支付代码。

活动和捐赠

在该方案允许付款人输入值的情况下,提供没有固定金额的可重复使用的代码。

跨境经营

发布不同的市场格式,而不是假设一种国内代码在任何地方都适用。

常见问题

一个支付二维码可以在每个国家使用吗?

不会。付款方案、货币、标识符和支持的应用程序有所不同。选择接收市场的格式。

创建代码可以转移金钱吗?

不,它只准备付款数据。付款人在兼容的应用程序中授权转账。

QRCode GEN可以确认收件人吗?

不会。银行应用程序可以解析并显示受益人;付款人必须验证。

为什么某些格式禁用样式控件?

HUB-3、瑞士 QR-bill 和 UPN 定义了条形码呈现细节。更改它们可能会破坏合规性或扫描。

为您的市场创建支付代码

选择标准,使用兼容的银行应用程序对其进行测试,并在发布前验证受益人。

创建支付二维码