OpenAPI-enabled payment development documentation released - Introducing the PG Multi-Payment Service Developer Documentation

Before you begin

PG Multi-Payment Service provides a mechanism that allows multiple payment method to be implemented uniformly in APIs by providing OpenAPI types.

For more information on the implementation method and design concept of the OpenAPI type, we introduced it in the previous article" payment Implementation is shortened to 2 days PayPay.​

In this article, we will introduce the technical features of the "developer documentation site" that we refer to when implementing OpenAPI types.

*

"Please order the specification through sales."

If you're an engineer with experience integrating with a PSP (payment service provider), you've probably faced this word at least once.

Even if you want to see the behavior of an API at the requirements definition stage, it takes days to access the specification---- many of you may be familiar with this experience.

GMO Payment Gateway (GMO-PG) launched a developer documentation site for PG Multi-Payment Service in March 2025.

On this site, you can refer to the information necessary for development, such as API references, connection methods, and use cases, on your browser.

This documentation site will explain in order the technical entities---- the interactive API execution environment that can be completed on the browser, OAS-compliant ecosystem collaboration, and the API design ---- that abstracts various payment method unique to Japan into "four payment types".

"Moving" is faster than "reading". API execution environment completed on the browser

The best feature of developer documentation sites is the interactive design that allows you to not only "read" the specifications, butalso "move" them on the fly.

▼API reference screen:An execution environment that allows you to execute API requests on the browser and check the response instantly

You can check the operation of the API with just a browser

When engineers want to understand the behavior of an API, they typically review the API specification, manually set the endpoint header parameters in a tool such as Postman or curl, and send a request to the sandbox environment to confirm.

The GMO-PG documentation site "Mulpay Docs" allows you to complete this work in your browser.Simply enter your API key for testing and any parameters from the reference screen for each API, and click the "Run API Request" button to issue an actual HTTP request to your sandbox environment and check the response on the spot.

In addition, we publish OpenAPI Spec files, so after understanding the behavior of APIs on the documentation site, we can import the same spec files into Postman to verify detailed cases and automatically generate client code for each development language.

​Automatically generate sample code covering major languages

In addition to running in the browser, sample code for major languages such as "Shell", "Node.js", "Ruby", "PHP", "Python", and "Java" is provided as standard in the right panel of the screen.

If you use the payment endpoint (POST /credit/charge) for each credit card, you can not only see the response at a glance at the time of success or error, as shown below, but alsoautomatically generate code snippets for each language that can be copied and pasted as they are.

{
  "nextAction": "NO_ACTION",
  "orderReference": {
    "orderId": "order-001"
  },
  "creditResult": {
    "transactionId": "txn_xxxxxxxxx",
    "authorizationCode": "123456"
  }
}

In parallel with checking the specification with documentation, you can actually run the request in the browser to get a faster and more accurate understanding of the API's behavior. These functions are included so that developers can verify and implement them smoothly.

Provision of "OpenAPI Spec Files" to Support Modern Development Flows

The documentation site provides an "OpenAPI Spec file" that defines the specifications for each API.

This is not just a document for humans to read and understand the specification. This file can be used by loading it directly into an API verification tool such as Postman or an automatic code generation tool.

By using this spec file, developers can automatically generate client code for each development language with a single command. This allows for a smooth "type-safe implementation" that prevents miswritten parameters and bugs in data types, reducing the man-hours required for payment integration.

Automatic Client Code Generation

By using this OpenAPI Spec file, developers can automatically generate client code for each development language with a single command.

# クライアントを自動生成するコマンド例 openapi-generator-cli generate -i ./gmo-pg-openapi.json -g typescript-fetch -o ./client

The generated client contains type definitions, so IDE input completion works, and type errors are statically detected when the payload is built. It warns of missing required fields or incorrect values before code execution, enabling a "type-safe implementation" that prevents bugs before they occur.

Abstraction of Japan's diverse payment method into "four payment types"

The payment environment in Japan has its own complexities. In addition to credit cards, there are various payment method unique to Japan, such as convenience store payment, Bank transfer, various pay-based payment, and career payment, each with different behaviors and business flows. The main feature of PG Multi-Payment Service 's API is that it classifies and abstracts this complex payment flow into four payment types: "credit card payment", "Pay", "cash payment", and "buy now pay later".

When you add a new payment method, you can see which payment type it belongs to, and you can apply the same type of logic (request response structure and state transitions) that you already implement.This significantly reduces the learning cost and implementation effort of understanding the specification from scratch with each new payment method.

This "improvement of development efficiency through abstraction" is also beneficial for the business side in terms of implementation speed and operational load. The business impact of OpenAPI types, which can reduce development man-hours for multiple payment method, such as PayPay and credit cards, is explained in detail in the related article below.

【Related Article】payment Reduced implementation to as little as 2 days. PayPay ・Credit cards are also introduced in bulk with API "OpenAPI type"

Developer testimonials using the pre-release version (beta version)

Prior to this general release, we have received the following feedback from development sites from companies that have tried out the new documentation site (beta version) in advance.

1. The information necessary for development has been organized and the time required for research has been reduced.
・From use cases to payment method selection, connection methods, and API specifications, it is systematically organized and related information can be checked at once.
・This reduces the amount of work that used to be done going back and forth between multiple materials, which leads to a reduction in the time it takes to confirm specifications.

2. Document structure that makes it easy to grasp the implementation image
・Sample code and example requests and responses are posted along with the API specification, making it easy to use as reference information for implementation.
・ payment The state transitions of the process are organized in diagrams, making it easy to understand the flow of transactions.

3. Easier to find necessary information and contribute to development efficiency
・By using the search function and AI assistant, you can quickly check the desired specifications and settings.
・ Information is organized by payment method and usage scene, making it easy to grasp specific implementation steps from the purpose you want to achieve.
・Documentation can be referenced from AI editors and other sources through llms.txt support, and AI-based development environments are also supported.

In general, we have heard that "we have created an environment where developers can focus on the original design and implementation of their own services rather than researching payment specifications," and we have heard that we have realized the efficiency of integration.

Evolving infrastructure with engineer feedback

payment integration is not an intrinsic engineering challenge. The value of an application lies in the experience beyond the payment flow, and the implementation of payment should be a "transit point" to get there.

However, the reality is that payment implementations have taken up more development time than many engineers expected. The time required to access documentation, the inquiry cycle to confirm unpublished specifications, ---- the cost of setting up a test environment were all "black boxes" that took away time that should have been devoted to development.

Publishing developer documentation sites is positioned as one way to change this situation. It opens up access to information, enables instant testing in the browser, and enables toolchain integration with OAS compliance. Through this cycle, the goal is to reduce the lead time required for integration.

ドキュメントサイトはリリースして完結するものではありません。実装上の疑問点、ドキュメントの不足箇所、APIデザインへのフィードバック----エンジニアの視点からの指摘が、次のアップデートの優先度を決める材料になります。 まずはドキュメントサイト（https://docs.gmo-pg.com/mulpay）にアクセスし、サンドボックス環境でリクエストを発行してみてください。各APIリファレンス画面の「API リクエストを実行」ボタンを数回クリックするだけで、このAPIの実装に何が必要かの輪郭を掴みやすくなるはずです。

Related Links

• PGマルチペイメントサービス開発者向けドキュメント

• 「PGマルチペイメントサービス」テストアカウント申込

• 決済実装を最短2日に短縮。PayPay・クレジットカードもAPIで一括導入「OpenAPIタイプ」

• PGマルチペイメントサービス概要
  

Supervisor

Takeshi Yoshida

In April 1995, he joined IBM Japan Co., Ltd. and worked as an IT architect mainly for banks. After that, he served as the Executive Manager for the operation of the company's convenience store ATM and bank switching center and regional bank Internet banking center. After many years of IT transformation of finance, he joined GMO Payment Gateway, Inc. in March 2019. Participated in the development of the QR platform and the launch and development of new payment platforms for group companies. As the current Management Department of Payment Service Director since October 2023, he will oversee the planning, development, and operation of "PG Multi-Payment Service". In addition to the stable operation of the platform that supports the largest payment processing Actual in Japan, he is also leading the provision of payment services that are close to the customer's business.

---

Supervisor

Shinji Yamaguchi

He joined GMO Payment Gateway, Inc. in 2018. Since joining the company, he has been consistently involved in the system development of the comprehensive payment service "PG Multi-Payment Service". He is mainly in charge of payment method areas other than credit cards, and is in charge of the development of the API-type linkage method "OpenAPI Type", which allows developers to flexibly incorporate payment functions, and promotes the release of the product. He has been involved in a wide range of initiatives, including adding payment method, revamping the system, and improving platform stability. Currently, as a general manager, he is in charge of controlling various projects and product management, and is promoting the evolution of services as a playing manager who is involved in development himself.