易宝开发文档
易宝支付是国内领先的第三方支付平台,其开放平台为开发者提供了稳定、安全的支付接入能力,本教程将深入解析易宝开发文档的核心内容,提供实战级的集成指导与最佳实践。

核心概念与准备工作
- 必备账号
- 商户号 (MerchantNo): 在易宝完成入驻签约后获得的核心身份标识。
- 主密钥 (SecretKey): 用于交易签名和验签的核心机密,绝对不可泄露,通过商户后台管理。
- 关键环境
- 沙箱环境 (Sandbox): 用于开发、调试和功能验证,提供模拟的支付流程和测试账号(如手机号、卡号)。
- 生产环境 (Production): 正式处理真实交易的环境,务必在沙箱充分测试后再切换。
- 理解支付流程
- 下单: 商户系统调用易宝API创建支付订单,获取支付跳转URL或二维码。
- 支付: 用户跳转至易宝收银台或唤起支付APP完成支付。
- 异步通知 (Callback): 支付结果由易宝服务器主动异步推送至商户预设的通知地址。
- 同步返回 (Return): 用户支付完成后同步跳转回商户页面(仅作展示,不可依赖)。
- 订单查询: 商户主动调用API查询订单状态(弥补通知丢失)。
核心API集成详解 (以网页支付为例)
-
下单请求 (Payment Request)
-
API地址:
/payment/v1/request -
核心参数:

merchantNo: 商户号orderId: 商户系统唯一订单号 (防重复支付关键)orderAmount: 订单金额 (单位:分)goodsName: 商品名称notifyUrl: 异步通知地址 (易宝POST支付结果至此URL)returnUrl: 支付完成同步跳转地址 (供用户返回)timestamp: 请求时间戳 (精确到毫秒)sign: 签名 (见下方签名机制)
-
签名机制 (SHA-256 with RSA):
# Python 示例 (使用pycryptodome) from Crypto.PublicKey import RSA from Crypto.Signature import pkcs1_15 from Crypto.Hash import SHA256 import base64 import urllib.parse import time import json # 假设参数已放入字典 params params = { 'merchantNo': 'your_merchant_no', 'orderId': 'ORDER_123456789', 'orderAmount': '10000', # 100元 'timestamp': str(int(time.time() 1000)), # ... 其他必填参数 } # 1. 参数排序、URL编码、拼接 sorted_params = sorted(params.items(), key=lambda x: x[0]) sign_str = '&'.join([f"{k}={urllib.parse.quote_plus(str(v))}" for k, v in sorted_params]) # 2. 加载商户私钥 (PKCS#8 格式) with open('merchant_private_key.pem', 'r') as f: private_key = RSA.import_key(f.read()) # 3. 生成SHA256哈希 hash_obj = SHA256.new(sign_str.encode('utf-8')) # 4. 使用私钥签名 signer = pkcs1_15.new(private_key) signature = signer.sign(hash_obj) # 5. Base64编码签名 sign_base64 = base64.b64encode(signature).decode('utf-8') # 6. 将签名 sign_base64 放入请求参数 params['sign'] 中 params['sign'] = sign_base64 -
响应处理: 解析易宝返回的JSON,获取
code(成功为0000),message, 核心是payUrl(支付跳转URL) 或qrCode(二维码内容)。
-
-
处理异步通知 (Critical!)
-
核心原则:
- 幂等性: 同一通知可能多次到达,需根据
orderId判断是否已处理。 - 验签: 必须验证签名合法性,防止伪造通知。
- 业务校验: 校验通知中的金额、订单号是否与本地记录一致。
- 幂等性: 同一通知可能多次到达,需根据
-
验签步骤:

# 假设从通知请求中获取所有参数 (易宝POST方式发送) notification_params = request.POST.dict() # Django示例 # 1. 提取签名 sign (通知参数里的) received_sign = notification_params.pop('sign', '') received_sign = base64.b64decode(received_sign) # 2. 构建待验签字符串 (同下单请求规则) sorted_notify = sorted(notification_params.items(), key=lambda x: x[0]) notify_str = '&'.join([f"{k}={urllib.parse.quote_plus(str(v))}" for k, v in sorted_notify]) # 3. 加载易宝公钥 (从商户后台获取或文档提供) with open('yeepay_public_key.pem', 'r') as f: yeepay_pub_key = RSA.import_key(f.read()) # 4. 生成SHA256哈希 hash_obj = SHA256.new(notify_str.encode('utf-8')) # 5. 使用公钥验签 verifier = pkcs1_15.new(yeepay_pub_key) try: verifier.verify(hash_obj, received_sign) # 验签成功,处理业务逻辑 order_id = notification_params['orderId'] status = notification_params['status'] # e.g., 'SUCCESS' # ... 检查本地订单状态、金额,更新订单为成功,发货等 # 务必返回 'SUCCESS' 字符串给易宝服务器,否则易宝会重试通知 return HttpResponse('SUCCESS') except (ValueError, TypeError): # 验签失败!记录日志,严重安全风险,不处理此通知 return HttpResponse('FAIL', status=400)
-
进阶技巧与避坑指南 (专业解决方案)
- 高并发与幂等性设计:
- 问题: 支付成功通知可能因网络问题被易宝重试多次。
- 方案: 在数据库订单表设计
status字段 (如INIT,PAID,FAILED),处理通知时:-- 使用乐观锁或数据库事务更新 UPDATE orders SET status = 'PAID' WHERE order_id = ? AND status = 'INIT'; -- 检查更新影响行数,如果为0,说明订单已处理过
- 网络超时与重试机制:
- 问题: 商户系统处理通知时调用自身服务(如更新库存)可能失败或超时。
- 方案:
- 通知接口处理逻辑应尽量轻量、快速。
- 将核心业务处理(发货、记账)放入异步队列(如RabbitMQ, Kafka),由消费者保证最终一致性。
- 通知接口成功接收并验签后,立即返回
SUCCESS,再异步处理业务。
- 安全加固:
- 敏感数据: 主密钥、私钥严禁硬编码或前端暴露,使用KMS或配置文件加密存储。
- IP白名单: 在易宝商户后台配置异步通知接收服务器的IP白名单。
- HTTPS: 确保
notifyUrl和returnUrl使用HTTPS协议。 - XSS/SQL注入防护: 对同步返回参数进行严格过滤和转义。
- 对账与差错处理:
- 每日对账: 务必通过易宝提供的对账文件接口(
/settlement/v1/balance_check_file),下载每日交易明细文件,与自身系统订单逐笔核对金额、状态、手续费。 - 差错处理: 发现金额不一致、状态不符的订单,及时通过易宝提供的差错处理接口或商户后台人工处理。
- 每日对账: 务必通过易宝提供的对账文件接口(
调试与最佳实践
- 善用沙箱: 模拟所有支付场景(成功、失败、超时)、测试通知接收和验签逻辑。
- 日志详尽: 记录关键步骤信息(请求/响应、通知内容、验签结果、业务处理状态),方便排查。
- 监控告警: 对通知接口错误率、未处理订单、对账差异设置监控告警。
- 文档版本: 关注易宝开放平台公告,及时更新API版本和SDK。
- SDK选择: 优先使用易宝官方提供的SDK (Java, PHP, .NET, Python等),可简化签名/验签流程,但务必理解其原理。
实战经验分享: 曾处理过因未做异步业务解耦,导致通知处理超时触发易宝重试,最终因数据库锁引发雪崩,解决方案是将核心发货逻辑移入消息队列,通知接口仅负责验签、更新订单基础状态和入队,系统稳定性显著提升。
你在集成易宝支付时遇到过最棘手的问题是什么?是签名验签失败、通知丢失,还是对账不平?欢迎在评论区分享你的踩坑经历和解决方案,共同探讨优化之道!
原创文章,作者:世雄 - 原生数据库架构专家,如若转载,请注明出处:https://idctop.com/article/17297.html