2024-12-02

PAY.JP の本番利用申請なしでどこまで試せるかやってみた。

この記事は PAY Advent Calendar 2024 2 日目の記事です。 qiita.com

こんばんは、zan_sakurai です。

今日は PAY.JP の本番利用申請なしでどこまで試せるかやってみた、ということで、実際に試してみた記録を共有しようと思います。

PAY.JP を試してみるまで。

めちゃくちゃスムーズです。

1.https://pay.jp/ にアクセス

2.今すぐ始められる。必要な情報を入力

3.メールが来るので、メール内のリンクをクリックする。

4.さて、テスト環境でのお試しに必要な情報は揃いました。

のめちゃくちゃ簡単なステップで私の場合 5 分もかからずで、テスト環境での利用が可能になりました。

ちなみにPAY.JP APIの curl などのリクエストはアカウント作成を行わずとも利用できたので、なにはともあれ試してみたい方にはおすすめかもしれません。

PAY.JP APIの curl を含めて、ここまでで約 6 分でした。

テスト環境での利用

さて、curl でのお試しも終わりましたので、実際にテスト環境と curl でも試してみようと思います。まずは顧客リストを取得から。サンプルのリクエストをほぼそのまま使えば OK で、顧客リストを 0 件で取得できました。

% curl 'https://api.pay.jp/v1/customers?limit=3&offset=10' \
-u sk_test_xxxxxxxxxxxxxxxxxxxxxxx:
{
  "count": 0,
  "data": [],
  "has_more": false,
  "object": "list",
  "url": "/v1/customers"
}%

せっかくなので顧客を作成も試してみようと思います。はいどーん...!

% curl https://api.pay.jp/v1/customers \
-u sk_test_xxxxxxxxxxxxxxxxxxxxxxx: \
-d description=test

{
  "cards": {
    "count": 0,
    "data": [],
    "has_more": false,
    "object": "list",
    "url": "/v1/customers/cus_xxxxxxxxxxxxxxxxxxxxxxx/cards"
  },
  "created": 1733152067,
  "default_card": null,
  "description": "test",
  "email": null,
  "id": "cus_xxxxxxxxxxxxxxxxxxxxxxx",
  "livemode": false,
  "metadata": {},
  "object": "customer",
  "subscriptions": {
    "count": 0,
    "data": [],
    "has_more": false,
    "object": "list",
    "url": "/v1/customers/cus_xxxxxxxxxxxxxxxxxxxxxxx/subscriptions"
  }
}%

できました。(そのあと何度か実行。)

改めて顧客リストを取得。
ちゃんと 6 件取得できました。(PAY.JP 顧客一覧にも表示されていました。)

curl 'https://api.pay.jp/v1/customers' \
-u sk_test_xxxxxxxxxxxxxxxxxxxxxxx:

{
  "count": 6,
  "data": [
    {

# 省略

一旦ここまでで 30 分もかからず...!

さいごに

すぐにお試しできるのは開発者にとって非常に有り難いと感じました。本懐のカード情報のトークン化 -> 支払い処理に関してはまだ試せていませんが、はじめに - PAY.JP ドキュメントを見る限り非常にかんたんそうではあるので、また試してみたいと思います。(1週間以内が目標...!)

2024-12-02

「1 円オーソリ」についてのメモ書き

この記事は PAY Advent Calendar 2024 2 日目の記事です。 qiita.com

こんばんは、zan_sakurai です。2 日連続ですいません。

昨日は、オンラインクレジットカード決済の「オーソリ」と「キャプチャ」についてについて書いてみました。
今日はまた業界用語の「1 円オーソリ」について書いていこうかと思います。

1 円オーソリについて。

1 円オーソリとは、その名の通りクレジットカード決済の際に、カードの有効性確認のために 1 円などの少額でオーソリを行うことです。
「1 円オーソリ」と今回は表現していますが、カードの有効性確認が目的ですので、必ずしも 1 円である必要はもちろんなく、商慣習的に 1 円オーソリと呼称されることが多いかと思います。

日本以外でも「1 円オーソリ」と同様の目的を持ったオーソリが行われており、ざっと調べたところ 1 ドルで行われていることが多いようです。

また、あくまでカードの有効性確認さえできれば良いので、最終的にキャプチャされるわけではなく、有効性確認が完了したら、そのオーソリはキャンセルされることが多いかと思います。

「1 円オーソリ」の期限や歴史を調べてみようかと思い、大雑把に調べてみましたが、有効な資料には現時点ではたどり着けませんでした。
とはいえ、商慣習的に根強く定着している「1 円オーソリ」ですので、単語だけでも覚えていただけるとよいかと思います。

ご利用いただいた方への説明がとても重要

「1 円オーソリ」は我々のようなサービス運営者や業界関係者にとっては馴染み深いものかと思いますが、一方で利用者にとってはとにかくわかりにくい仕様のうちの 1 つです。
実際にオーソリが行われていますので、身に覚えのない「1 円」の明細があれば、不安になる方も多いかと思います。(最終的にはキャプチャされずにキャンセルされるので引き落としはされませんが、一時的とはいえ、1 円などの少額が明細に載るのは不安になるかと思います。)

この不安感を解消するには、ご利用いただいた方に安心していただくために、この「1 円オーソリ」の正体についての説明をヘルプページを用意するなど親切丁寧に説明することが重要かと思います。 (「1 円明細」「1 円請求」などで検索すると、ヘルプページで親切丁寧に説明しているサービスが多い！と感じました。英語で検索してみても類似のヘルプページが多く、説明が重要であることがわかります。)

まとめ

いかがでしたでしょうか。２日連続でごちゃごちゃと書いてしまい申し訳ない気持ちでいっぱいですが、今日は「1 円オーソリ」について書いてみました。

これから初めてオンラインクレジットカード決済を実装して導入する開発者や、オンラインクレジットカード決済について詳しく知りたい方にとって、きっかけの一助になると嬉しいです。

「1 円オーソリ」は、ヘルプページで親切丁寧に説明することでご利用いただいた方に安心していただきましょう。

2024-12-01

オンラインクレジットカード決済の「オーソリ」と「キャプチャ」について

決済

この記事は PAY Advent Calendar 2024 1 日目の記事です。 qiita.com

こんばんは、zan_sakurai です。

記念すべき個人ブログ第一号の記事です。(これまで「個人で情報発信やるぞやるぞ」とずっと思っていたり言いはじめて 10 年弱経過していました...。)
普段はとある EC 関連プロダクトの開発に携わっているエンジニアをしています。

今回は、オンラインクレジットカード決済の「オーソリ」と「キャプチャ」について整理してみました。
これから初めてオンラインクレジットカード決済を実装して導入する開発者や、オンラインクレジットカード決済について詳しく知りたい方にとって、一助になると嬉しいです。

「オーソリ」「キャプチャ」って何？

「オーソリ」「キャプチャ」という用語は、我々?のようなオンラインクレジットカード決済に関わったことがある人々にとっては馴染みのある言葉かもしれません。
しかし、一般の利用者にとっては、あまり馴染みのある言葉ではないかと思います。

オーソリとキャプチャは、ざっくり以下と解釈しています。

オーソリ: 支払いが可能かどうかを確認し、支払い金額を一時的に「確保」するプロセス。
キャプチャ: オーソリで確保した支払い金額を確定させるプロセス。

ここで急ですが、PAY.JP のドキュメントをみてみましょう。
PAY.JP#認証と支払い確定の冒頭によると

クレジットカードによる支払いは、認証と支払い確定の 2 つのステップにより行われます。認証では、クレジットカードの与信枠（限度額）の検証が行われ、支払い金額分の与信枠を確保します。支払い確定では、認証により与信枠が確保された金額の支払いを確定します。明細書に記載される請求金額には、支払い確定されたものが掲載されます。 PAY.JP では、認証と支払い確定を同時に行う通常の支払い処理と、認証と支払い確定を個別のリクエストで行う支払い処理をサポートしています。ここでは後者について説明します。

引用元 : PAY.JP#認証と支払い確定 https://pay.jp/docs/authcapture

との記載があります。

ここで挙げられている「認証」と「支払い確定」が、それぞれ「オーソリ」と「キャプチャ」に相当するものです。
また、同時に行われる場合もありますが、「オーソリ」-> 「キャプチャ」の順番で行われることをご認識いただけたかと思います。

「オーソリ」「キャプチャ」のタイミング

前章では、「オーソリ」「キャプチャ」の意味を再確認しましたが、次に「オーソリ」「キャプチャ」のタイミングについても考えてみようかと思います。
「オーソリ」「キャプチャ」のタイミングは提供する商材やサービスの性質によって異なりますが、以下の性質を考慮して決定すると良いかもしれません。

オーソリには有効期限が存在する: オーソリには有効期限があります。この期間内にキャプチャをおこなわないと、オーソリは自動的にキャンセルされ、キャプチャすることができなくなります。
オーソリとキャプチャのタイムラグ: オーソリとキャプチャは同時に行うこともできますが、別々のタイミングで行うこともできます。オーソリとキャプチャのタイムラグを設けることで、顧客に商品を提供する前にキャンセルすることができます。

PAY.JP では以下 2 つの支払い処理を提供しているようですので、それぞれのユースケースを考えてみようかと思います。

「認証と支払い確定を同時に行う通常の支払い処理」
「認証と支払い確定を個別のリクエストで行う支払い処理」

まず「認証と支払い確定を同時に行う通常の支払い処理」の場合、つまり「オーソリ」と「キャプチャ」を同時に行う場合について考えてみます。
これは例えば、オンラインで購入したソフトウェア、動画、音楽などのデジタルコンテンツなどの即時に利用できる商材などが該当するかと思います。
即時に顧客に商品が提供されますので、「キャプチャ」が完了したことを確実にする必要があるためです。

次に「認証と支払い確定を個別のリクエストで行う支払い処理」の場合、つまり「オーソリ」と「キャプチャ」を個別のリクエストで行う場合について考えてみます。
これは例えば、イベントのチケットなどの抽選などが該当するかと思います。
抽選申し込み時点でオーソリで与信枠を確保し、当選者のみキャプチャを行うような設計とした場合、当選者以外の方には支払いを行わせることなく、オーソリのキャンセルのみで対応することができます。
また、当選者は既にオーソリで与信枠を確保していますので、キャプチャのみで支払いを完了させることができます。（仮に当選してからオーソリ->キャプチャを行うと、当選したにも関わらず与信枠が足りない場合、支払いができないといった問題も発生するかと思います。）

「キャンセル」と「返金」

「オーソリ」「キャプチャ」と合わせて、オンラインクレジットカード決済において重要なプロセスとして「キャンセル」と「返金」があるかと思います。
これまで何度か触れてきましたが、以下のような違いがあるかと思います。

キャンセル:
- オーソリのキャンセル。オーソリをキャンセルすることで、与信枠を解放するプロセスを指す場合が多いように思います。
- キャプチャのキャンセル。キャプチャは支払いを確定していますので、返金を行うことで支払いの取り消しとするプロセスを指す場合が多いように思います。表現として少しややこしくなります。
返金:
- オーソリの返金。オーソリには返金の概念は有りません。
- キャプチャ後の返金。キャプチャは支払いを確定していますので、返金を行うことで支払いの取り消しとするプロセスを指す場合が多いように思います。

まとめ

少しごちゃごちゃしてしまいましたが、オンラインクレジットカード決済において重要なプロセスである「オーソリ」「キャプチャ」について整理してみました。加えて、「キャンセル」と「返金」についても触れてみました。

まだごちゃごちゃしているので、また別の機会でももう少し整理できたらな、と思います。