Back to Details

integrate-easypaisa

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Integrate Easypaisa

集成Easypaisa

Build Easypaisa payments from the merchant's current approved integration guide, not from copied legacy snippets. Easypaisa documentation and enabled payment modes can differ by merchant agreement and environment.
请依据商户当前获批的集成指南构建Easypaisa支付功能，切勿复制遗留代码片段。Easypaisa的文档及可用支付模式可能因商户协议和环境而异。

First: detect the existing integration

第一步：检测现有集成

Inspect the repository for Easypaisa/Easypay packages, plugins, gateway clients, merchant/store IDs, hash-key configuration, environment URLs, hosted checkout forms, mobile-account or OTC flows, return/callback/postback routes, transaction-status verification, reversal handling, order fields, settlement jobs, tests, and deployment secrets.
  • If an integration exists, identify the guide/version it implements, enabled modes, environment, signing/canonicalization rules, endpoints, order lifecycle, and known failures. Repair it incrementally and preserve certified behavior.
  • If no integration exists, design it using the project's existing stack and the merchant's latest onboarding/integration pack.
  • Never invent or copy credential names, request fields, endpoint URLs, hash ordering, algorithms, response codes, status values, or callback rules. Verify each against current merchant documentation and test vectors.
检查代码仓库中是否存在Easypaisa/Easypay包、插件、网关客户端、商户/店铺ID、哈希密钥配置、环境URL、托管结账表单、移动账户或OTC流程、返回/回调/回传路由、交易状态验证、撤销处理、订单字段、结算任务、测试及部署密钥。
  • 若已存在集成，请明确其实现的指南/版本、启用的模式、环境、签名/规范化规则、端点、订单生命周期及已知故障。逐步修复并保留已认证的行为。
  • 若不存在集成，请结合项目现有技术栈及商户最新的入驻/集成包进行设计。
  • 切勿自行编造或复制凭证名称、请求字段、端点URL、哈希排序、算法、响应码、状态值或回调规则。需对照商户当前文档及测试向量逐一验证。

Confirm the product and merchant eligibility

确认产品及商户资质

Official Easypaisa material currently advertises Online Payment Gateway onboarding for a business/entity with a live website or mobile app, subject to application, documentation, KYC/due diligence, and integration. Publicly listed modes include Easypaisa Mobile Account and OTC; plugins are listed for WooCommerce, OpenCart, Magento, and PrestaShop. Actual enabled modes, fees, settlement, limits, and technical contracts must come from the merchant agreement.
Do not confuse the Online Payment Gateway with a personal wallet transfer, merchant QR/Till, payment link, bulk disbursement, bank card acquirer, escrow, or recurring-subscription engine. Confirm the required Easypaisa product before coding.
Easypaisa官方资料目前宣传，拥有活跃网站或移动应用的企业/实体可申请线上支付网关入驻，需经过申请、提交文档、KYC/尽职调查及集成流程。公开列出的模式包括Easypaisa移动账户和OTC；同时提供适用于WooCommerce、OpenCart、Magento及PrestaShop的插件。实际启用的模式、费率、结算方式、限额及技术合约需以商户协议为准。
请勿将线上支付网关与个人钱包转账、商户二维码/收银台、支付链接批量付款、银行卡收单、托管或定期订阅引擎混淆。编码前请确认所需的Easypaisa产品类型。

Workflow

工作流程

  1. Obtain the latest merchant integration guide, sandbox/staging details, approved payment modes, credentials, test accounts/data, signature examples, callback rules, status/reversal APIs, certification cases, settlement terms, and production cutover pack.
  2. Record the exact guide/API/plugin version and compare it with existing code.
  3. Create an internal pending order with a unique merchant order/reference ID before starting payment.
  4. Calculate product, quantity, amount, currency, discounts, delivery, and customer ownership on the server. Never accept authoritative payment values from the client.
  5. Generate the request and integrity value exactly from the documented fields, order, encoding, and algorithm. Keep signing secrets server-side.
  6. Send customers only through the contracted hosted/direct/mobile-account/OTC flow. Use HTTPS return and server-notification URLs.
  7. Treat the browser return as user experience only. Verify and deduplicate the server callback/postback, then confirm ambiguous outcomes with the approved status mechanism or merchant portal.
  8. Fulfill once after server-side verification. Record transaction, order, channel, status, and settlement identifiers for support and reconciliation.
  9. Implement failure, cancellation, timeout, duplicate, delayed callback, reversal, refund where supported, and settlement-mismatch paths.
  10. Test in staging with approved cases and complete merchant certification/approval before live mode.
  1. 获取最新的商户集成指南、沙箱/ staging环境详情、获批的支付模式、凭证、测试账户/数据、签名示例、回调规则、状态/撤销API、认证案例、结算条款及生产环境切换包。
  2. 记录确切的指南/API/插件版本，并与现有代码进行对比。
  3. 在开始支付前，创建带有唯一商户订单/参考ID的内部待处理订单。
  4. 在服务器端计算商品、数量、金额、货币、折扣、配送费用及客户归属信息。切勿接受客户端传来的权威支付数值。
  5. 严格按照文档规定的字段、顺序、编码方式及算法生成请求和完整性校验值。签名密钥需保存在服务器端。
  6. 仅通过约定的托管/直接/移动账户/OTC流程引导客户完成支付。使用HTTPS返回地址和服务器通知URL。
  7. 浏览器返回仅作用户体验用途。需验证并去重服务器回调/回传信息，若结果不明确，需通过获批的状态机制或商户门户进行确认。
  8. 仅在服务器端验证通过后执行一次订单履约操作。记录交易、订单、渠道、状态及结算标识，以便后续支持及对账。
  9. 实现故障、取消、超时、重复、延迟回调、撤销、退款（若支持）及结算不匹配的处理流程。
  10. 在staging环境中使用获批案例进行测试，并完成商户认证/审批后再切换至生产模式。

Non-negotiable rules

不可协商的规则

  • Never expose merchant credentials or hash/signing keys in browser code, mobile apps, repositories, logs, screenshots, or errors.
  • Never mark an order paid from query parameters, a success page, client JSON, SMS, screenshot, or redirect alone.
  • Verify message integrity using the exact official canonicalization; timing-safe comparison is required where the application compares digests.
  • Enforce unique order and external transaction identifiers and make fulfillment idempotent.
  • Treat timeout or lost response as unknown—not failed—until verified.
  • Use integer minor units or the exact decimal formatting required by the guide; never binary floating point.
  • Do not retry charge/payment creation blindly.
  • Do not perform live payments, reversals, refunds, or credential changes without explicit approval.
  • 切勿在浏览器代码、移动应用、代码仓库、日志、截图或错误信息中暴露商户凭证或哈希/签名密钥。
  • 不得仅通过查询参数、成功页面、客户端JSON、短信、截图或重定向就标记订单已支付。
  • 使用官方明确的规范化方式验证消息完整性；当应用对比摘要时，必须使用时序安全的对比方法。
  • 强制使用唯一的订单和外部交易标识，并确保履约操作具有幂等性。
  • 超时或丢失响应需视为未知状态而非失败状态，直至验证确认。
  • 使用整数最小单位或指南要求的确切小数格式；切勿使用二进制浮点数。
  • 切勿盲目重试扣款/支付创建操作。
  • 未经明确批准，不得执行实时支付、撤销、退款或凭证变更操作。

Reference routing

参考路由

  • Read references/integration-workflow.md for order states, hosted/mobile-account/OTC flows, callbacks, verification, plugins, and testing.
  • Read references/security-and-operations.md before implementing signing, secrets, idempotency, reconciliation, monitoring, or production rollout.
  • Read references/research-notes.md for dated official sources, current public claims, community evidence, and details that must be re-verified.
  • 阅读references/integration-workflow.md了解订单状态、托管/移动账户/OTC流程、回调、验证、插件及测试相关内容。
  • 在实现签名、密钥、幂等性、对账、监控或生产环境部署前，请阅读references/security-and-operations.md。
  • 阅读references/research-notes.md获取过时的官方来源、当前公开声明、社区证据及需重新验证的细节。

Verification and output

验证与输出

Run relevant formatter, static analysis/type checking, tests, and builds. Report whether Easypaisa was found or added from scratch, the product/modes and guide version used, flows implemented, callback verification, idempotency, transaction-status recovery, reconciliation, certification status, and remaining merchant-portal configuration. Clearly separate public research, merchant-provided specifications, staging evidence, and live approval.
运行相关的格式化工具、静态分析/类型检查、测试及构建流程。报告是否已找到Easypaisa集成或从零开始添加、所使用的产品/模式及指南版本、已实现的流程、回调验证、幂等性、交易状态恢复、对账、认证状态及剩余的商户门户配置。需明确区分公开研究资料、商户提供的规范、staging环境证据及实时批准信息。