payment-provider-framework

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Payment Provider Framework (VTEX IO)

When this skill applies

适用场景

Use this skill when:

Creating or maintaining a payment connector implemented as a VTEX IO app (not a standalone HTTP service you host yourself)

Wiring

@vtex/payment-provider

PaymentProvider

, and

PaymentProviderService

node/index.ts

Configuring the
```
paymentProvider
```
builder,
```
configuration.json
```
(payment methods,
```
customFields
```
, feature flags)
Implementing
```
this.retry(request)
```
for Gateway retry semantics on IO
Extending
```
SecureExternalClient
```
and passing
```
secureProxy
```
on requests for card flows on IO
Testing via payment affiliation, workspaces, beta/stable releases, the VTEX App Store, and VTEX homologation

Do not use this skill for:

PPP HTTP contracts, response field-by-field requirements, and the nine endpoints in the abstract — use
```
payment-provider-protocol
```
Idempotency and duplicate
```
paymentId
```
handling — use
```
payment-idempotency
```
Async
```
undefined
```
status,
```
callbackUrl
```
notification vs retry (IO vs non-IO) — use
```
payment-async-flow
```
PCI rules, logging, and token semantics beyond IO wiring — use
```
payment-pci-security
```

本指南适用于以下场景：

创建或维护以VTEX IO应用形式实现的支付连接器（而非您自行托管的独立HTTP服务）

在

node/index.ts

中关联

@vtex/payment-provider

、

PaymentProvider

和

PaymentProviderService

配置
```
paymentProvider
```
构建器、
```
configuration.json
```
（支付方式、
```
customFields
```
、功能开关）
实现
```
this.retry(request)
```
以适配IO上的网关重试语义
继承
```
SecureExternalClient
```
并在IO上的卡支付流程请求中传入
```
secureProxy
```
参数
通过支付关联、工作区、beta/稳定版本发布、VTEX应用商店和VTEX homologation流程进行测试

本指南不适用于以下场景：

PPP HTTP契约、逐字段响应要求和抽象层面的9个端点——请参考
```
payment-provider-protocol
```
幂等性和重复
```
paymentId
```
处理——请参考
```
payment-idempotency
```
异步
```
undefined
```
状态、
```
callbackUrl
```
通知与重试（IO与非IO场景差异）——请参考
```
payment-async-flow
```
PCI规则、日志、IO关联之外的令牌语义——请参考
```
payment-pci-security
```

Decision rules

决策规则

PPF on IO: Payment Provider Framework is the VTEX IO–based way to build payment connectors. The app uses IO infrastructure; API routes, request/response types, and Secure Proxy are integrated per VTEX guides. Start from the example app described in Payment Provider Framework (clone/bootstrap as documented there).
Prerequisites: Follow Implementation prerequisites in the Payment Provider Protocol article and Integrating a new payment provider on VTEX.
Dependencies: In the app
```
node
```
folder, add
```
@vtex/payment-provider
```
(for example
```
1.x
```
in
```
package.json
```
). Keep
```
@vtex/api
```
in
```
devDependencies
```
(for example
```
6.x
```
); linking may bump it beyond
```
6.x
```
, which is acceptable. If
```
@vtex/api
```
types break, delete
```
node_modules
```
and
```
yarn.lock
```
in the project root and in
```
node
```
, then run
```
yarn install -f
```
in both.
paymentProvider
builder: In
```
manifest.json
```
, include
```
"paymentProvider": "1.x"
```
next to
```
node
```
so policies for Payment Gateway callbacks and PPP routes apply.
configuration.json
: Declare
```
paymentMethods
```
so the builder can implement them without re-declaring everything on
```
/manifest
```
. Use names that match List Payment Provider Manifest; only invent a new name when the method is genuinely new. New methods in Admin may require a support ticket.
PaymentProvider
: One class method per PPP route; TypeScript enforces shapes — see Payment Flow endpoints in the API reference.

PaymentProviderService
: Registers default routes

/manifest

/payments

/settlements

/refunds

/cancellations

/inbound

; pass extra

routes

clients

when needed.

Overriding
/manifest
: Only with an approved use case — open a ticket. See Preferred pattern for an example route override shape.

Configurable options: Use

configuration.json

/ builder options for flags such as

implementsOAuth

implementsSplit

usesProviderHeadersName

useAntifraud

usesBankInvoiceEnglishName

usesSecureProxy

requiresDocument

acceptSplitPartialRefund

usesAutoSettleOptions

(auto-settlement UI — Custom Auto Capture). Set

name

and rely on auto-generated

serviceUrl

on IO unless documented otherwise.

Gateway retry: In PPF, call
```
this.retry(request)
```
where the protocol requires retry — see Payment authorization in the PPP article.
Card data on IO: Prefer
```
SecureExternalClient
```
with
```
secureProxy: secureProxyUrl
```
from Create Payment; destination must be allowlisted (AOC via support). Supported
```
Content-Type
```
values for Secure Proxy:
```
application/json
```
and
```
application/x-www-form-urlencoded
```
only.
Checkout testing: Account must be allowed for IO connectors (ticket with app name and account). Publish beta, install on
```
master
```
, wait ~1 hour, open affiliation URL, enable test mode and workspace, configure payment condition (~10 minutes), place test order; then stable + homologation.
Publication: Configure
```
billingOptions
```
per Billing Options; submit via Submitting your app. Prepare homologation artifacts (connector app name, partner contact, production endpoint, allowed accounts, new methods/flows) per Integrating a new payment provider on VTEX (SLA often ~30 days).
Updates: Ship changes in a new beta, re-test affiliations, then stable; re-homologate if required.

IO上的PPF: Payment Provider Framework是基于VTEX IO构建支付连接器的官方方案。应用使用IO基础设施；API路由、请求/响应类型和Secure Proxy均按照VTEX指南集成。请从Payment Provider Framework文档中描述的示例应用开始开发（按照文档说明克隆/初始化项目）。
前置要求: 遵循Payment Provider Protocol文档中的实现前置要求以及在VTEX上集成新支付提供商指南。
依赖: 在应用的
```
node
```
文件夹中添加
```
@vtex/payment-provider
```
依赖（例如
```
package.json
```
中指定
```
1.x
```
版本）。将
```
@vtex/api
```
保留在
```
devDependencies
```
中（例如
```
6.x
```
版本）；link操作可能会将版本提升到
```
6.x
```
以上，这是可接受的。如果
```
@vtex/api
```
类型报错，请删除项目根目录和
```
node
```
目录下的
```
node_modules
```
和
```
yarn.lock
```
，然后在两个目录下分别执行
```
yarn install -f
```
。
paymentProvider
构建器: 在
```
manifest.json
```
中，在
```
node
```
旁边添加
```
"paymentProvider": "1.x"
```
配置，这样支付网关回调和PPP路由的权限策略就会生效。
configuration.json
: 声明
```
paymentMethods
```
，这样构建器就可以自动实现对应的能力，不需要在
```
/manifest
```
中重复声明所有内容。使用的名称要与支付提供商Manifest列表中的名称匹配；只有当支付方式确实是全新的时候才自定义新名称。在管理后台添加新支付方式可能需要提交支持工单。
PaymentProvider
: 每个PPP路由对应一个类方法；TypeScript会强制校验数据结构——参考API参考中的支付流程端点。

PaymentProviderService
: 注册默认路由

/manifest

、

/payments

、

/settlements

、

/refunds

、

/cancellations

、

/inbound

；需要时可以传入额外的

routes

clients

配置。

重写
/manifest
: 只有在有获批用例的情况下才能重写——需要提交工单。路由重写的示例结构请参考推荐模式部分。
可配置选项: 使用
```
configuration.json
```
/构建器选项来配置功能开关，例如
```
implementsOAuth
```
、
```
implementsSplit
```
、
```
usesProviderHeadersName
```
、
```
useAntifraud
```
、
```
usesBankInvoiceEnglishName
```
、
```
usesSecureProxy
```
、
```
requiresDocument
```
、
```
acceptSplitPartialRefund
```
、
```
usesAutoSettleOptions
```
（自动结算UI——参考自定义自动捕获）。除非另有文档说明，否则请设置
```
name
```
并依赖IO上自动生成的
```
serviceUrl
```
。
网关重试: 在PPF中，当协议要求重试时调用
```
this.retry(request)
```
——参考PPP文档中的支付授权部分。
IO上的卡数据: 优先使用
```
SecureExternalClient
```
，并传入创建支付时返回的
```
secureProxy: secureProxyUrl
```
；目标地址必须在白名单中（通过支持团队提交AOC申请）。Secure Proxy支持的
```
Content-Type
```
仅为
```
application/json
```
和
```
application/x-www-form-urlencoded
```
。
结账测试: 账户必须被允许使用IO连接器（提交包含应用名称和账户信息的工单）。发布beta版本，安装到
```
master
```
工作区，等待约1小时，打开关联URL，启用测试模式和对应工作区，配置支付条件（约10分钟），提交测试订单；之后发布稳定版本并完成homologation流程。
发布: 按照计费选项文档配置
```
billingOptions
```
；通过提交应用流程提交到应用商店。按照在VTEX上集成新支付提供商要求准备homologation材料（连接器应用名称、合作伙伴联系方式、生产环境端点、允许的账户、新支付方式/流程），SLA通常约为30天。
更新: 在新的beta版本中发布变更，重新测试关联流程，然后发布稳定版本；如果需要的话重新走homologation流程。

Hard constraints

硬性约束

Constraint: Declare the

paymentProvider

builder and a real connector identity in

configuration.json

约束：在

configuration.json

中声明

paymentProvider

构建器和真实的连接器标识

IO connectors MUST include the

paymentProvider

builder in

manifest.json

and a

paymentProvider/configuration.json

with a non-placeholder

name

and accurate

paymentMethods

. Do not ship the literal placeholder

"MyConnector"

(or equivalent) as production configuration.

Why this matters

Without the builder, PPP routes and Gateway policies are not wired. A placeholder name breaks Admin, affiliations, and homologation.

Detection

manifest.json

lacks

paymentProvider

, or

configuration.json

still uses example placeholder names, stop and fix before publishing.

Correct

json

{
  "name": "PartnerAcmeCard",
  "paymentMethods": [
    { "name": "Visa", "allowsSplit": "onCapture" },
    { "name": "BankInvoice", "allowsSplit": "onAuthorize" }
  ]
}

Wrong

json

{
  "name": "MyConnector",
  "paymentMethods": []
}

IO连接器必须在

manifest.json

中包含

paymentProvider

构建器，同时在

paymentProvider/configuration.json

中填写非占位符的

name

和准确的

paymentMethods

。不要将字面量占位符

"MyConnector"

（或等效内容）作为生产配置发布。

重要性

没有该构建器的话，PPP路由和网关策略不会被关联。占位符名称会导致管理后台、关联流程和homologation流程出错。

检测方式

如果

manifest.json

缺少

paymentProvider

配置，或者

configuration.json

仍然使用示例占位符名称，请在发布前修复问题。

正确示例

json

{
  "name": "PartnerAcmeCard",
  "paymentMethods": [
    { "name": "Visa", "allowsSplit": "onCapture" },
    { "name": "BankInvoice", "allowsSplit": "onAuthorize" }
  ]
}

错误示例

json

{
  "name": "MyConnector",
  "paymentMethods": []
}

Constraint: Register PPP routes only through

PaymentProviderService

with a

PaymentProvider

implementation

约束：仅通过

PaymentProviderService

配合

PaymentProvider

实现来注册PPP路由

The service MUST wrap a class extending

PaymentProvider

from

@vtex/payment-provider

so standard PPP paths are registered. Do not hand-roll the same route surface without the package unless VTEX explicitly prescribes an alternative.

Why this matters

Missed or mismatched routes break Gateway calls and homologation; the package keeps handlers aligned with the protocol.

Detection

node/index.ts

exposes PPP paths manually and does not instantiate

PaymentProviderService

with the connector class, reconcile with the documented pattern.

Correct

typescript

import { PaymentProviderService } from "@vtex/payment-provider";
import { YourPaymentConnector } from "./connector";

export default new PaymentProviderService({
  connector: YourPaymentConnector,
});

Wrong

typescript

// Ad-hoc router only — no PaymentProviderService / PaymentProvider base
export default someCustomRouterWithoutPPPPackage;

服务必须封装继承自

@vtex/payment-provider

中

PaymentProvider

的类，这样才能注册标准的PPP路径。除非VTEX明确指定替代方案，否则不要在不使用该包的情况下手动实现相同的路由表层。

重要性

缺失或不匹配的路由会导致网关调用和homologation流程失败；该包可以保证处理逻辑与协议保持一致。

检测方式

如果

node/index.ts

手动暴露PPP路径，且没有使用连接器类实例化

PaymentProviderService

，请按照文档中的模式调整。

正确示例

typescript

import { PaymentProviderService } from "@vtex/payment-provider";
import { YourPaymentConnector } from "./connector";

export default new PaymentProviderService({
  connector: YourPaymentConnector,
});

错误示例

typescript

// 仅使用自定义路由——没有使用PaymentProviderService / PaymentProvider基类
export default someCustomRouterWithoutPPPPackage;

Constraint: Use

this.retry(request)

for Gateway retry on IO

约束：在IO上使用

this.retry(request)

实现网关重试

Where the PPP flow requires retry semantics on IO, handlers MUST invoke

this.retry(request)

as specified in the protocol — not a custom retry helper that bypasses the framework.

Why this matters

The Gateway expects framework-driven retry behavior; omitting it causes inconsistent authorization and settlement behavior.

Detection

Search payment handlers for protocol retry cases; if retries are implemented without

this.retry

, fix before release.

Correct

typescript

// Inside a PaymentProvider subclass method, when the protocol requires retry:
return this.retry(request);

Wrong

typescript

// Re-implementing gateway retry with setTimeout/fetch instead of this.retry
await fetch(callbackUrl, { method: "POST", body: JSON.stringify(payload) });

当IO上的PPP流程要求重试语义时，处理逻辑必须按照协议规定调用

this.retry(request)

——不要使用绕过框架的自定义重试工具。

重要性

网关期望框架驱动的重试行为；缺少该实现会导致授权和结算行为不一致。

检测方式

在支付处理逻辑中搜索协议要求重试的场景；如果重试实现没有使用

this.retry

，请在发布前修复。

正确示例

typescript

// 在PaymentProvider子类方法内部，当协议要求重试时：
return this.retry(request);

错误示例

typescript

// 使用setTimeout/fetch重新实现网关重试，而不是使用this.retry
await fetch(callbackUrl, { method: "POST", body: JSON.stringify(payload) });

Constraint: Forward card authorization calls through Secure Proxy on IO with allowlisted destinations

约束：IO上的卡授权调用需要通过Secure Proxy转发，且目标地址在白名单中

For card flows on IO with

usesSecureProxy

behavior, proxied HTTP calls MUST go through

SecureExternalClient

(or equivalent VTEX pattern), MUST pass

secureProxy

set to the

secureProxyUrl

from the payment request, and MUST target a VTEX-allowlisted PCI endpoint. Only

application/json

application/x-www-form-urlencoded

bodies are supported. If

usesSecureProxy

is false, the provider must be PCI-certified and supply AOC for

serviceUrl

per VTEX.

Why this matters

Skipping Secure Proxy or wrong content types breaks PCI scope, proxy validation, or acquirer integration — blocking homologation or exposing card data incorrectly.

Detection

Inspect client code for POSTs that include card tokens without

secureProxy

in the request config, or destinations not registered with VTEX.

Correct

typescript

import { SecureExternalClient, CardAuthorization } from "@vtex/payment-provider";
import type { InstanceOptions, IOContext, RequestConfig } from "@vtex/api";

export class MyPCICertifiedClient extends SecureExternalClient {
  constructor(protected context: IOContext, options?: InstanceOptions) {
    super("https://pci-certified.example.com", context, options);
  }

  public authorize = (cardRequest: CardAuthorization) =>
    this.http.post(
      "authorize",
      {
        holder: cardRequest.holderToken,
        number: cardRequest.numberToken,
        expiration: cardRequest.expiration,
        csc: cardRequest.cscToken,
      },
      {
        headers: { Authorization: "Bearer ..." },
        secureProxy: cardRequest.secureProxyUrl,
      } as RequestConfig
    );
}

Wrong

typescript

// Direct outbound call with raw card fields and no secureProxy
await http.post("https://acquirer.example/pay", { pan, cvv, expiry });

对于IO上带有

usesSecureProxy

配置的卡支付流程，代理HTTP调用必须通过

SecureExternalClient

（或等效的VTEX标准模式）实现，必须将

secureProxy

设置为支付请求返回的

secureProxyUrl

，且必须指向VTEX白名单中的PCI端点。仅支持

application/json

或

application/x-www-form-urlencoded

格式的请求体。如果

usesSecureProxy

为false，提供商必须通过PCI认证，并按照VTEX要求提供

serviceUrl

的AOC。

重要性

跳过Secure Proxy或使用错误的内容类型会破坏PCI范围、代理校验或收单机构集成——会导致homologation流程被阻塞，或卡数据暴露风险。

检测方式

检查客户端代码中包含卡令牌的POST请求，是否在请求配置中没有携带

secureProxy

，或者目标地址未在VTEX注册。

正确示例

typescript

import { SecureExternalClient, CardAuthorization } from "@vtex/payment-provider";
import type { InstanceOptions, IOContext, RequestConfig } from "@vtex/api";

export class MyPCICertifiedClient extends SecureExternalClient {
  constructor(protected context: IOContext, options?: InstanceOptions) {
    super("https://pci-certified.example.com", context, options);
  }

  public authorize = (cardRequest: CardAuthorization) =>
    this.http.post(
      "authorize",
      {
        holder: cardRequest.holderToken,
        number: cardRequest.numberToken,
        expiration: cardRequest.expiration,
        csc: cardRequest.cscToken,
      },
      {
        headers: { Authorization: "Bearer ..." },
        secureProxy: cardRequest.secureProxyUrl,
      } as RequestConfig
    );
}

错误示例

typescript

// 直接调用外部接口，传递原始卡字段，且没有使用secureProxy
await http.post("https://acquirer.example/pay", { pan, cvv, expiry });

Preferred pattern

Common failure modes

常见失败场景

Missing
```
paymentProvider
```
builder or empty/wrong
```
paymentMethods
```
so
```
/manifest
```
and Admin do not list methods correctly.
Type or install drift (
```
@vtex/api
```
/
```
@vtex/payment-provider
```
) without the clean reinstall path in root and
```
node
```
.
Skipping
```
this.retry(request)
```
and duplicating retry with ad-hoc HTTP — Gateway behavior diverges from PPP.
Card calls without
```
secureProxy
```
, wrong
```
Content-Type
```
, or non-allowlisted destination — Secure Proxy or PCI review fails.
Testing without account allowlisting, without sellable products, or without waiting for master install / payment condition propagation.
Overriding
```
/manifest
```
without VTEX approval or leaving stale
```
x-provider-app
```
after a major version bump.
Homologation ticket missing production endpoint, allowed accounts, or purchase-flow details (Purchase Flows).

缺少
```
paymentProvider
```
构建器，或者
```
paymentMethods
```
为空/配置错误，导致
```
/manifest
```
和管理后台无法正确列出支付方式。
类型或安装版本漂移（
```
@vtex/api
```
/
```
@vtex/payment-provider
```
），没有按照要求在根目录和
```
node
```
目录下执行干净重装。
没有使用
```
this.retry(request)
```
，而是通过自定义HTTP请求重复实现重试逻辑——网关行为与PPP协议不一致。
卡支付请求没有使用
```
secureProxy
```
、
```
Content-Type
```
错误，或者目标地址不在白名单中——Secure Proxy或PCI审核失败。
测试时没有将账户加入白名单、没有可售商品，或者没有等待master工作区安装完成/支付条件配置生效。
没有获得VTEX批准就重写
```
/manifest
```
，或者在主版本升级后没有更新
```
x-provider-app
```
导致配置过期。
Homologation工单缺少生产环境端点、允许的账户或者购买流程详情（参考购买流程）。

Review checklist

审核检查清单

Is the connector an IO app using
```
PaymentProvider
```
+
```
PaymentProviderService
```
(not only a standalone middleware guide)?
Do
```
manifest.json
```
and
```
paymentProvider/configuration.json
```
match the real connector name and supported methods?
Are optional manifest overrides ticket-approved and are
```
handler
```
/ headers /
```
x-provider-app
```
correct?
Does every route implementation align with types in
```
@vtex/payment-provider
```
and with
```
payment-provider-protocol
```
for response shapes?
Are Gateway retries implemented with
```
this.retry(request)
```
where required?
Do card flows use
```
SecureExternalClient
```
(or equivalent) with
```
secureProxy: secureProxyUrl
```
and allowlisted destinations?
Has beta/staging testing followed affiliation, test mode, workspace, and payment condition steps before stable?
Are billing, App Store submission, and homologation prerequisites documented in the internal release checklist?

连接器是否是使用
```
PaymentProvider
```
+
```
PaymentProviderService
```
的IO应用（而非仅独立中间件指南）？
```
manifest.json
```
和
```
paymentProvider/configuration.json
```
是否与真实的连接器名称和支持的支付方式匹配？
可选的manifest重写是否经过工单批准，
```
handler
```
/请求头/
```
x-provider-app
```
是否正确？
每个路由实现是否与
```
@vtex/payment-provider
```
中的类型以及
```
payment-provider-protocol
```
中的响应结构一致？
要求的场景下是否使用
```
this.retry(request)
```
实现了网关重试？
卡支付流程是否使用
```
SecureExternalClient
```
（或等效模式），传递了
```
secureProxy: secureProxyUrl
```
，且目标地址在白名单中？
发布稳定版本前，beta/ staging测试是否遵循了关联、测试模式、工作区和支付条件配置步骤？
内部发布检查清单中是否记录了计费、应用商店提交和homologation的前置要求？

Related skills

Reference

参考

Payment Provider Framework — Official PPF guide (includes getting started and example app)
Payment Provider Protocol API overview
Secure Proxy
PCI DSS compliance (payments)
Payment Provider Protocol (Help Center)
Integrating a new payment provider on VTEX

Payment Provider Framework——官方PPF指南（包含入门和示例应用）
Payment Provider Protocol API概述
Secure Proxy
PCI DSS合规（支付）
Payment Provider Protocol（帮助中心）
在VTEX上集成新支付提供商

payment-provider-framework

Original

Translation

Payment Provider Framework (VTEX IO)

Payment Provider Framework (VTEX IO)

When this skill applies

适用场景

Decision rules

决策规则

Hard constraints

硬性约束

Constraint: Declare the
`paymentProvider`
builder and a real connector identity in
`configuration.json`

约束：在
`configuration.json`
中声明
`paymentProvider`
构建器和真实的连接器标识

Constraint: Register PPP routes only through
`PaymentProviderService`
with a
`PaymentProvider`
implementation

约束：仅通过
`PaymentProviderService`
配合
`PaymentProvider`
实现来注册PPP路由

Constraint: Use
`this.retry(request)`
for Gateway retry on IO

约束：在IO上使用
`this.retry(request)`
实现网关重试

Constraint: Forward card authorization calls through Secure Proxy on IO with allowlisted destinations

约束：IO上的卡授权调用需要通过Secure Proxy转发，且目标地址在白名单中

Preferred pattern

推荐模式

Common failure modes

常见失败场景

Review checklist

审核检查清单

Related skills

相关指南

Reference

参考

payment-provider-framework

Original

Translation

Payment Provider Framework (VTEX IO)

Payment Provider Framework (VTEX IO)

When this skill applies

适用场景

Decision rules

决策规则

Hard constraints

硬性约束

Constraint: Declare the paymentProvider builder and a real connector identity in configuration.json

约束：在configuration.json中声明paymentProvider构建器和真实的连接器标识

Constraint: Register PPP routes only through PaymentProviderService with a PaymentProvider implementation

约束：仅通过PaymentProviderService配合PaymentProvider实现来注册PPP路由

Constraint: Use this.retry(request) for Gateway retry on IO

约束：在IO上使用this.retry(request)实现网关重试

Constraint: Forward card authorization calls through Secure Proxy on IO with allowlisted destinations

约束：IO上的卡授权调用需要通过Secure Proxy转发，且目标地址在白名单中

Preferred pattern

推荐模式

Common failure modes

常见失败场景

Review checklist

审核检查清单

Related skills

相关指南

Reference

参考

Constraint: Declare the
`paymentProvider`
builder and a real connector identity in
`configuration.json`

约束：在
`configuration.json`
中声明
`paymentProvider`
构建器和真实的连接器标识

Constraint: Register PPP routes only through
`PaymentProviderService`
with a
`PaymentProvider`
implementation

约束：仅通过
`PaymentProviderService`
配合
`PaymentProvider`
实现来注册PPP路由

Constraint: Use
`this.retry(request)`
for Gateway retry on IO

约束：在IO上使用
`this.retry(request)`
实现网关重试