OpenAPIタイプ 概要

OpenAPIタイプの全体像、実現できる決済処理、導入までの流れやテストについて説明します。

OpenAPIタイプ用語集

支払いタイプ

OpenAPIタイプでは、決済手段を支払いの特徴ごとに4つの支払いタイプに分類しています。
APIは支払いタイプごとに集約された構成になっています。

• OpenAPIタイプの4つの支払いタイプ
  • クレカ払い
  • Pay払い
  • 現金払い
  • 後払い

Webhook

一部の支払いタイプにおいて、取引状態に更新があった際に、加盟店様にHTTPプロトコルを使用して通知する仕組みです。

OpenAPIタイプの特徴

簡単かつ安全に利⽤いただくことを⽬指し、RFCやOpenAPI SpecificationなどのWeb標準に従っています。
加えて、決済手段の追加や不正利用への対応を柔軟に行えるよう最適化されています。
技術的特徴は以下の通りです。

• OpenAPI Specification(OAS)に準拠
  OpenAPI Generatorなどのツールを使ってコードの一部自動生成やモックサーバーの構築ができます。 OASの標準に従っているので、API仕様を理解しやすく、開発負荷を削減し、接続作業を効率化します。

• Remote Procedure Call(RPC/遠隔手続き呼び出し)に基づいた設計
  決済処理の特性をAPIで表現するには、「リソース」操作をベースとしたREST形式ではなく、「手続き」をリクエストするRPC形式が最適です。
  全てのAPIはアクションで表され、HTTPメソッドはPOSTで統一されています。
  つまり、照会や削除のリクエストAPIであってもRESTとは異なりHTTPメソッドはPOSTです。
  ペイロードはJSON形式で表すこと、HTTPステータスコードでレスポンスの内容を表す様式は、使い慣れたRESTと同じです。

• 冪等性(Idempotency)をサポート
  二重決済となる心配はありません。同一の冪等キーを設定した支払いリクエストを何度リトライしても、支払い処理は一回しか行われず同じレスポンスが返ります。
  ネットワークエラーなどの場合に加盟店様から自動リトライすれば、不整合となった支払いリクエストを安全に修復できます。
  決済データの一貫性を保ち、加盟店様サービスのお客様にも安心してご利用いただける環境を提供します。

他にも末永く安心して使っていただけるよう以下の特徴を提供します。

• 簡単な決済手段追加
  支払いタイプごとに集約したAPI構成になっています。
  決済手段追加時の開発コストを削減できるので、貴社ビジネス部門からの「この決済手段を試したい」という要望に迅速に対応できます。

• 決済の不正利用を防止
  あらゆる不正検知ソリューションに対応しています。
  クレカ払いAPIに統合されているため、追加の開発は必要ありません。
  また、お客様の多要素認証をサポートする本人確認機能をご利用いただけます。

• 高度なセキュリティ対策
  APIの通信はTLS(SSL)による暗号を必須としており、政府機関レベルの強固な暗号化方式のみを許可しています。
  また、APIへのアクセス認証においては、従来のパスワード方式に加えて、より安全性の高いOAuth 2.0を利用したアクセストークン方式もサポートします。
  PCI DSS(Payment Card Industry Data Security Standard)に準拠した内部システムでは、全ての個人情報が暗号化されています。
  私たちのシステムは常に最新のセキュリティ標準にアップデートしており、お客様に安心してご利用いただける環境を提供しています。

また、OpenAPIタイプと従来のプロトコルタイプ/モジュールタイプには互換性があります。
現在プロトコル/モジュールタイプをご利⽤の加盟店様は、簡単にOpenAPIタイプへ移行できます。
取引の情報や登録済みの会員データはそのまま利⽤ができ、ショップの情報や各種設定は変わりません。
管理画⾯、SFTP取引情報配信、SFTP⼀括処理などはこれまで通りご利⽤になれます。
詳細はプロトコルタイプ/モジュールタイプからの移行を参照してください。

支払い機能

PGマルチペイメントサービスが提供する決済機能をOpenAPIタイプでどのように扱うかを説明します。

支払いパターン

タイミングやお客様操作の有無により、支払いパターンは以下の3つに分類されます。

支払いパターン	説明	OpenAPIタイプでの取り扱い
都度支払い one-off	支払いの都度、お客様が決済に必要な情報入力や手続きをする支払いパターンです。 例） クレジットカード番号を入力しての支払い Amazonアカウントに登録してあるクレジットカードを使ったAmazon Pay V2での支払い 払い出された決済番号を使った、コンビニでの支払い	OpenAPIタイプに 対応している全ての決済手段で利用できます。
随時支払い on-file	支払いに必要な番号や認証情報を当サービスに事前に保管しておき、お客様が都度の情報を入力することなくお支払いができる支払いパターンです。 オートチャージのように一定の条件下でお客様の操作なく支払いを完了させる場合も含まれます。 以下の「定期支払い」と同様の仕組みを加盟店様システム内にて構築する場合は「随時支払い」をご利用ください。 例） 当サービスに保管済みの番号を設定したクレジットカード支払い 当サービスに保管済みの認証情報を設定してログイン遷移なく実施する楽天ペイ(オンライン決済)V2での支払い	OpenAPIタイプに 対応している決済手段のうち、一部の決済手段で利用できます。
定期支払い recurring	決められたスケジュール、決められた金額での支払いを継続する支払いパターンです。 例） 当サービスに保管済みのカード番号を利用して、自動で毎月10日に会費1,000円をクレジットカードで支払い	現在は利用できません。 今後、クレジットカード決済のみ対応予定です。

クレカ払い

項目	説明
決済手段	・クレジットカード ・Google Pay ・Apple Pay Apple Pay以外は3Dセキュアに対応しています。
処理の流れと 支払い成立条件	加盟店様サイトからの支払いリクエストを受けると、 当サービスからカード会社にオーソリ（信用照会）を行います。 カード会社から与信成功が返れば支払い成立です。支払いの結果はレスポンスとして即時返ります。 3Dセキュア認証を行う場合は、一度外部の認証機関に遷移した後にオーソリを行います。
随時支払い(on-file) への対応	当サービスに保管したカード情報を利用して随時支払いが可能です。 Google Payのアカウントそのものを保管して随時支払いはできません。 ただし、実際に使用されたクレジットカードを保管してクレカ払いとして随時支払いに利用できます。 Apple Payは、VISAブランド以外で随時支払いに対応していますが、利用できなくなる可能性があります。
対応するAPI	都度支払い（/credit/charge）API 随時支払い（/credit/on-file/charge）API

Pay払い

項目	説明
決済手段	・PayPay ・d払い ・楽天ペイ(オンライン決済)V2 ・Amazon Pay V2 ・au PAY(ネット支払い)アプリ方式 ・メルペイ ・Alipay ・AEON Pay 本番環境でのAlipayの利用開始時期は調整中です。
処理の流れと 支払い成立条件	加盟店様サイトからの支払いリクエスト後に、 別のサイトやアプリに遷移し、お客様自身による同意が必要です。 Pay払い提供会社の認証が成功して加盟店様サイトが設定したURLに遷移したタイミングで、 支払いを成立させてください。
随時支払い(on-file) への対応	Alipay・AEON Payを除くPay払いで認証情報を保管できます。 利用には事前の承諾が必要です。詳細は利用承諾（/wallet/authorizeAccount）APIを参照してください。 AEON Payは2026年3月以降に利用できる予定です。
対応するAPI	都度支払い（/wallet/charge）API 随時支払い（/wallet/on-file/charge）API

現金払い

項目	説明
決済手段	・コンビニ ・Pay-easy ・銀行振込(バーチャル口座) ・マイペイメント
処理の流れと 支払い成立条件	加盟店様サイトからの支払い要求リクエストを受けて、 決済機関に対して支払いに必要な情報を要求します。 支払い番号などの情報が返るため、加盟店様からお客様に通知してください。 お客様が支払うと、当サービスから加盟店様にWebhookで通知します。 この通知を受け取ったタイミングで支払いを成立させてください。
随時支払い(on-file) への対応	利用できません。
対応するAPI	支払い番号発行（/cash/charge）API

後払い

項目	説明
決済手段	・アトカラ
処理の流れと 支払い成立条件	加盟店様サイトからの支払い要求リクエストを受けて、 決済機関に対して支払いに必要な情報を要求します。 アトカラでは、決済事業者提供のJS SDKを用いて決済要求を行う必要があります。 詳細はアトカラ 概要を参照してください。
随時支払い(on-file) への対応	利用できません。
対応するAPI	出荷報告（/deferredpay/shipping）API 出荷取消（/deferredpay/shippingCancel）API 出荷変更（/deferredpay/shippingUpdate）API 取引変更（/deferredpay/orderUpdate）API

本人確認機能

PGマルチペイメントサービスが提供する本人確認機能VerifyサービスをOpenAPIタイプでどのように扱うかを説明します。
Verifyサービスは、お客様の会員登録時、ログイン認証時、属性情報変更時など任意のタイミングにおいて、多様な認証手段で本人確認ができる機能です。
複数の認証手段を簡易に単一のAPIでまとめて導入することができます。

本人確認の認証手段

利用可能な認証手段は以下の通りです。

認証手段	お客様のデータ	処理の流れ
SMS認証	携帯電話番号	加盟店様サイトからのリクエストを受けると お客様の携帯電話に認証コード（6桁数値）を送信します。 お客様は当サービスが提供する画面にて認証コードを入力します。 認証成功後は加盟店様サイトが設定したURLに戻ります。

※今後はマイナンバーカードを使った本人確認（マイナIC認証）への対応も予定しています。

プロトコルタイプ/モジュールタイプからの移行

プロトコルタイプ/モジュールタイプは引き続き利用いただけますが、より便利なOpenAPIタイプに移行することを推奨します。
前述の通り、OpenAPIタイプと従来の接続方式には互換性があり併用が可能です。
例えば取引の確定をするスケジュール処理を先⾏して実装するといった柔軟な移⾏が可能です。
詳細な情報については、プロトコルタイプ対応表を参照してください。

プロトコルタイプ/モジュールタイプとOpenAPIタイプで共通して取り扱うデータについて説明します。

データ	説明
ショップID	共通して利用でき、変更の必要はありません。 テスト環境のショップIDも同様です。
ショップパスワード	共通して利用でき、変更の必要はありません。 管理画面からパスワードを変更した場合、両方に反映されます。
サイトID	OpenAPIタイプでは利用しません。 ショップIDの設定により、紐づくサイトIDが自動で利用されます。 カード登録時の処理料ご請求先は、これまで通り請求先ショップです。
サイトパスワード	OpenAPIタイプでは利用しません。
取引ID	共通の仕様で発行され、両方で利用できます。
取引パスワード	OpenAPIタイプでは利用しません。 元の取引を指定する場合は取引IDのみで行います。
取引ステータス	共通して利用できます。
オーダーID	共通して利用できます。
会員ID	共通して利用できます。
登録済みカード	共通して利用できます。ただし、OpenAPIタイプでは削除済み状態のカードで支払いできません。
カード登録連番モード	OpenAPIタイプでは利用しません。 従来の「物理モード」が標準ですが、「論理モード」もサポートします。
カード登録連番	OpenAPIタイプでは従来の「物理登録連番」を「カードID」と表します。 「論理登録連番」は「カードインデックス」として扱います。

従来のプロトコルタイプ/モジュールタイプとOpenAPIタイプには、一部の仕様に差異があります。
移行においては、特に以下の点にご注意ください。

• OpenAPIタイプでは、一部の決済手段を除いて従来の「結果通知」はサポートしていません。
  タイムアウトなどでレスポンスが返らない場合は、同一の冪等キーを設定してリトライをお願いします。
  詳細については結果通知(Webhook通知)を参照してください。
• モバイルEdy決済、モバイルSuica決済など、OpenAPIタイプに対応していない決済手段があります。詳細は各決済手段のページを参照してください。
• 金額と税送料は統合しました。税送料は個別に設定できません。
• 個別の加盟店様向けの特殊機能やオプションパラメーターは利用できません。
• プロトコルタイプ/モジュールタイプで取引登録を行った取引に対してOpenAPIタイプで処理を行った場合、従来の「結果通知」仕様に則り通知がされます。
• プロトコルタイプ/モジュールタイプのカード登録/更新(SaveCard)では、物理モードで登録連番を指定せずに登録済みのカード番号を指定した場合、同一のカード番号を「新規登録」ではなく「更新」として処理しますが、OpenAPIタイプでは「新規登録」として扱います。
• 登録済みカード情報のデフォルトフラグを付け替える機能は提供していません。