入金関連の機能を追加しました

PAY.JPでは日々機能の追加を行なっています。

今回お問い合わせに寄せられたご要望にお応えして入金関連の機能を2つ追加いたしました。

  1. テストモードで入金オブジェクトを作成するようにしました

    今まで入金オブジェクトは入金が発生しないテストモードでは作成していなかったのですが、テストモードでも確認したいとの要望があり作成することにしました。

    テストモードの入金オブジェクトはプランの締め日に応じて月1,2回入金準備中もしくは入金繰越しステータスで作成されます。 テストモードでは実際に入金されることはありません。

  2. 入金の内訳CSVに項目を追加しました

    入金の内訳CSVで顧客のデータや手数料を把握したいとの要望があり以下の項目を追加しました。

    • fee_rate : 手数料率
    • fee : 手数料
    • customer[email] : 顧客のメールアドレス
    • customer[description] : 顧客の概要

PAY.JPでは今後も機能を拡張していきます。 何かご要望がありましたらお問い合わせからご連絡をいただけると幸いです。

PAY.JP で Google Chrome の Payment Request API を使って決済する

こんにちは @wozozo です花金です。

Android の Google Chrome 53 以降、デスクトップ版の Chrome 60 以降では Payment Request API に対応しています。これに対応しているブラウザであれば、毎回クレジットカード情報の入力をすることなく Google Chrome に保存されているカード情報を使って簡単に決済を行うことが可能です。

f:id:payjp:20170609145950p:plain

まず前提として、Payment Request API が提供する機能は決済に必要なカード情報の受け渡しであり、カード情報を受け取ったにあとに実際に決済を行うためには PAY.JP のような決済ゲートウェイを別途利用する必要があります。

ECサイトによって必要な機能の違いはあると思いますが、クライアント側の実装は基本的に以下のコードだけで済みます。 (Google Developers のサイトにサンプルコードが掲載されているのをほぼそのまま貼り付けました)

<script type="text/javascript" src="https://js.pay.jp/"></script>
<script>
// payjpjs のセットアップ
Payjp.setPublicKey("pk_test_0383a1b8f91e8a6e3ea0e2a9");

function onBuyClicked() {
  if (!window.PaymentRequest) {
    // PaymentRequest API is not available. Forwarding to
    // legacy form based experience.
    location.href = '/checkout';
    return;
  }

  // Supported payment methods
  var supportedInstruments = [{
      supportedMethods: ['basic-card'],
      data: {
        supportedNetworks: [
          'visa', 'mastercard', 'amex', 'discover',
          'diners', 'jcb', 'unionpay'
        ]
      }
  }];

  // Checkout details
  var details = {
    displayItems: [{
      label: 'ダンベル40kg + 20kgサービス',
      amount: { currency: 'JPY', value: '10800' }
    }, {
      label: '送料',
      amount: { currency: 'JPY', value: '20000' }
    }],
    total: {
      label: '合計',
      amount: { currency: 'JPY', value : '30800' }
    }
  };

  // 1. Create a `PaymentRequest` instance
  // 1. `PaymentRequest` インスタンスを生成する
  var request = new PaymentRequest(supportedInstruments, details);

  // 2. Show the native UI with `.show()`
  // 2. `.show()` を呼び出して、ネイティブ UI を表示する
  request.show()
  // 3. Process the payment
  // 3. 決済処理をおこなう
  .then(result => {
    // POST the payment information to the server

    const card = {
        number: result.details.cardNumber,
        exp_month: result.details.expiryMonth,
        exp_year: result.details.expiryYear,
        cvc: result.details.cardSecurityCode,
    };

    Payjp.createToken(card, function(status, response) {
      if (status == 200) {
        document.getElementById('result').innerText = `PAY.JP Token: ${response.id}`;
        return result.complete('success');
      } else {
        // handle error like displaying error message.
        return result.complete('fail');
      };
    });

  });
}

document.querySelector('#start').addEventListener('click', onBuyClicked);
</script>

コード自体の説明は元のページで解説されているのでご覧ください。

実際に決済をする場合、生のカード番号・有効期限・CVC等を載せて PAY.JP にリクエストを送る必要がありますが、それらの情報はコード中2番の request.show() を呼び出した後、3番の then に PaymentResponse という形で入ってきます。

f:id:payjp:20170609150612p:plain

生カード番号をサーバー側で一時的にも受け取らなくていいように、ここでは payjp.js SDK を使用しています。これを使うと、iframe 上で PAY.JP ドメインと https で通信をしてカード番号をトークン化したものが返却されます。このトークンを使用することで、ECサイト側などではカード情報に一切触れずに決済処理を行うことが可能です。

ここまではクライアント側だけで済ませられますので、このトークンを使用し、通常の PAY.JP 決済と同様にサーバー側で charge を作成すると決済が完了します。(カード番号やCVCは決して保存しないでください。)

サーバー側のサンプルコードは下のようになります。

const express = require('express');
const app = express();
const bodyParser = require('body-parser');
const payjp = require('payjp')('sk_test_c62fade9d045b54cd76d7036');

app.use(express.static(__dirname + '/views'));
app.use(bodyParser.json());

app.get('/', function (req, res) {
  res.render('index');
})

app.post('/pay-with-token', function (req, res) {
  const query = {
    amount: 30800, // 本来はリクエストの中身から取得,
    currency: 'jpy',
    card: req.body.token // tok_xxx の PAY.JP Token を取得
  };
  payjp.charges.create(query).then((result) => {
    // サーバー側での決済成功時に必要な処理 etc
    res.json({success: true});
  }).catch((err) => {
     console.error(err);
     res.json({success: false});
  });
})

app.listen(3000, function () {
  console.log('Example app listening on port 3000!');
})

デスクトップ版の Chrome であれば OS を選ばずに使用できます。

f:id:payjp:20170609151208p:plain

モバイル、デスクトップ版いずれの場合も決済ダイアログの「お支払い」ボタンを押した際に CVC の入力が求められますが、ユーザーにはそれ以外の入力は求められません。

https://i.gyazo.com/530c8cbb212653fab6e0d14415fee88b.gif

Payment Request API が使えるブラウザの種類はまだ多くないですが、決済手段の選択肢として必要十分な機能が提供されており、実装もごく少量のコードでできるため、Google Chrome のシェアが多いサイトでは現実的な選択肢の一つとして候補に挙げられると思います。 また、日本ではまだ開始されていないため今回は紹介しませんでしたが、 Android Pay と統合することもでき、Android Pay にクレジットカードが登録されていれば Payment Request API のダイアログ上の選択肢として Visa・Mastercard などの並びに表示されます。

PAY.JP で Payment Request API をぜひお試しください。

記事中に掲載したコードは GitHub にも公開しています。

github.com

参考

年次の定期課金、はじめました

こんにちは、Takumaです。

今までは月に一度課金を実行する月次プランの定期課金のみがサポート対象でしたが、年に一度課金を実行できる年次プランのサポートを本日開始しました。

年次プランとその定期課金の作成

年次プランを作成するには、期間(interval) にyearを指定します。以下が年次プラン作成リクエストのサンプルです。

リクエスト:

curl https://api.pay.jp/v1/plans \
-u sk_test_c62fade9d045b54cd76d7036: \
-d amount=775 \
-d currency=jpy \
-d interval=year \
-XPOST

以下のようなレスポンスが返れば、年次プランの作成は成功です。

レスポンス:

{
  "amount": 775,
  "billing_day": null,
  "created": 1484278427,
  "currency": "jpy",
  "id": "pln_72eb1066416083d0a70d67531751",
  "interval": "year",
  "livemode": false,
  "metadata": {},
  "name": null,
  "object": "plan",
  "trial_days": 0
}

上のプランidを定期課金作成APIで指定すれば、年次の定期課金を作成することができます。以下がサンプルリクエストです。

リクエスト:

curl https://api.pay.jp/v1/subscriptions \
-u sk_test_c62fade9d045b54cd76d7036: \
-d plan=pln_72eb1066416083d0a70d67531751 \
-d customer=cus_5de245838f5c36462b328534b9b4 \
-XPOST

年次定期課金の作成に成功すると以下のようなレスポンスが返ります。

レスポンス:

{
  "canceled_at": null,
  "created": 1484279234,
  "current_period_end": 1515815234,
  "current_period_start": 1484279234,
  "customer": "cus_5de245838f5c36462b328534b9b4",
  "id": "sub_a95d445900798b36b10c72d6b8d6",
  "livemode": false,
  "metadata": {},
  "object": "subscription",
  "paused_at": null,
  "plan": {
    "amount": 775,
    "billing_day": null,
    "created": 1484278427,
    "currency": "jpy",
    "id": "pln_72eb1066416083d0a70d67531751",
    "interval": "year",
    "livemode": false,
    "metadata": {},
    "name": null,
    "object": "plan",
    "trial_days": 0
  },
  "prorate": false,
  "resumed_at": null,
  "start": 1484279234,
  "status": "active",
  "trial_end": null,
  "trial_start": null
}

この時点で、初回分の課金は実行済みです。次回の課金実行日時(current_period_end)は作成日時からちょうど1年後です(上の例だと2018年1月13日 3:47am UTC)。

年次プランについて

年次プランは期間(interval)がyearのプランです。このプランを購読してる定期課金は更新周期が一年になります。

トライアル日数(trial_days)を設定することは可能ですが、課金日(billing_day)を設定することはできません。

プラン変更について

定期課金のプラン変更は、変更前と変更後のプランの期間(interval)が異なる場合でも可能です。

プラン変更時に、課金周期が更新されるのは、以下のいずれかが当てはまるケースです。

  • 日割り課金設定が無効
  • 更新前と更新後のプラン期間が異なる
  • 更新前と更新後のプラン課金日が異なる
  • 変更時にトライアル(trial_end)が付与される

トライアルが付与された場合を除き、プラン変更時には課金が実行されます。 課金金額の計算式等に関して、詳しくはこちらの記事を参照ください。

月次と年次プランを組み合わせて利用することにより、PAY.JPをご利用しているサービスの有料オプションに幅を持たせる事ができます。ぜひご利用ください。

WebPay 公式移行サポート開始のお知らせ

先日のWebPayのサービス終了のアナウンスを受け、PAY.JPではWebPayからPAY.JPへ移行する方法について一次アナウンスをさせていただきました。

WebPay サービス終了にあたっての PAY.JP への移行方法 - PAY.JP Engineering Blog

その後WebPayと調整を進めまして、カード番号とCustomers Objectの具体的な移行に関する詳細が固まりましたので、該当情報の移行先を検討している事業者の皆さまに向けて、ご案内いたします。

移行対象について

今回のデータ移行の目的は、WebPayしか保有していないカード番号を移行するための救済策となっており、その他APIで事業者側から取得可能な情報については、移行できない場合があることを予めご了承ください。

これをふまえた上、WebPayとPAY.JP間で移行が保証される、保証されない、移行されない情報は下記のとおりとなります。

移行が保証される情報 移行が保証されない情報 移行されない情報
Customers: id
Customers の active_card: type, last4, exp_year, exp_month, name
Customers の active_card: country, cvc_check Customers: id 以外
Customers の active_card: fingerprint
Charges
Tokens
Recursions
Events
Account

WebPayとPAY.JP間ではCustomersの id とカード番号、及び付随するカード情報のペアでデータ移行を実施予定です。

「移行が保証される情報」は、事業者のみなさまがWebPayで管理されていた情報がそのままPAY.JPに移行されます。 ( name は255文字を超える長さの場合、移行できません)

「移行が保証されない情報」も同様にWebPayで管理されていた情報がそのままPAY.JPに移行されます。( cvc_check については文字列に違いがあるので、両API リファレンスから確認してください) このデータは、先述の通り状況により移行ができかねるケースがございます。

「移行されない情報」は、Customersの id 以外、Customers以外のObjectとなっております。Customersのactive_cardの fingerprint についてはPAY.JPの仕様で生成されるため、WebPayで管理されていた fingerprint とは異なる値が生成されます。

Charges Objectは、PAY.JP側で決済トランザクションが発生していない都合で、返金や売上確定などの後続処理がシステム的に不可能なため、移行できません。Recursions Objectの移行については、後述する説明を参照してください。

また cvc はPCI-DSSの観点から取扱できないセンシティブデータとなっており、移行対象となっておりません。

移行サンプル

下記にサンプルデータを用いて「移行される情報」(移行が保証されない情報を含む)がWebPayからPAY.JPでどのようにデータが変化するかをJSONで示します。

WebPayで生成したサンプルcustomerのデータ:

{
  "id": "cus_2uc0JYeED5OPbxG",
  "object": "customer",
  "livemode": false,
  "created": 1478828555,
  "email": "payjp@example.com",
  "description": "サンプルユーザー",
  "active_card": {
    "object": "card",
    "exp_year": 2020,
    "exp_month": 12,
    "fingerprint": "215b5b2fe460809b8bb90bae6eeac0e0e0987bd7",
    "name": "TARO YAMADA",
    "country": "JP",
    "type": "Visa",
    "cvc_check": "pass",
    "last4": "4242"
  },
  "recursions": [
  ]
}

上記を移行した場合のPAY.JPのデータ:

{
  "cards": {
    "count": 1,
    "data": [
      {
        "address_city": null,
        "address_line1": null,
        "address_line2": null,
        "address_state": null,
        "address_zip": null,
        "address_zip_check": "unchecked",
        "brand": "Visa",
        "country": "JP",
        "created": 1478828796,
        "customer": "cus_2uc0JYeED5OPbxG",
        "cvc_check": "passed",
        "exp_month": 12,
        "exp_year": 2020,
        "fingerprint": "e1d8225886e3a7211127df751c86787f",
        "id": "car_ed7cc52bd41be35b3159572f73a1",
        "last4": "4242",
        "livemode": false,
        "metadata": {},
        "name": "TARO YAMADA",
        "object": "card"
      }
    ],
    "has_more": false,
    "object": "list",
    "url": "/v1/customers/cus_2uc0JYeED5OPbxG/cards"
  },
  "created": 1478828796,
  "default_card": "car_ed7cc52bd41be35b3159572f73a1",
  "description": null,
  "email": null,
  "id": "cus_2uc0JYeED5OPbxG",
  "livemode": false,
  "metadata": {},
  "object": "customer",
  "subscriptions": {
    "count": 0,
    "data": [],
    "has_more": false,
    "object": "list",
    "url": "/v1/customers/cus_2uc0JYeED5OPbxG/subscriptions"
  }
}

「移行される情報」がWebPayからPAY.JPへ引き継がれ、「移行されない情報」が引き継がれていないことが確認できます。

WebPayにおけるカード情報Object customer.active_card はhashなのに対し、PAY.JPでは customer.cards というarrayになっていることにご注意ください。PAY.JPでは1つのCustomerに対して複数のカード情報を紐付けることができるので、 customer.cards というarrayとなっています。

移行の流れ

移行の流れについて、具体的には下記の流れにて停止期間なく、移行を進めることが可能です。下記手順はPAY.JPへの移行を前提としたものです。

  1. WebPayとPAY.JPの双方に決定の連絡をしてください
  2. 事業者側で接続するシステムの実装を行って稼働させてください
    a. PAY.JPで新規登録、メール認証、および本番申請を済ませておいてください
  3. 新規の取引については、WebPayではなく、PAY.JPで決済を実行するように設定を行い、WebPayに新たにカード情報が増えない状態を作ってください
    a. WebPayの既存の顧客情報による取引は、WebPayのシステムで実行するよう設定してください
  4. WebPay側で新規のカード情報追加が行われなくなったことを確認してから、カード情報のデータ移管をWebPayとPAY.JPの両方へ依頼してください
    a. データ移管の受付期限は3/31 23:59までです
  5. WebPayからPAY.JPにPCI DSSに準拠した形でカード情報のデータ移管を実施します
    a. データ移管の最終実施日は4/30です
  6. PAY.JPでデータ取込手続きを実施した上で、事業者側にデータ移管完了の連絡が来て、すべての手続が完了します
    a. PAY.JPのデータ取込は、手順5完了より2営業日以内を目安に実施いたします

データ移行のタイミングやその他細かい調整については、個別にやり取りしてサポートさせていただければと思います。

まずはWebPay、またはPAY.JPへ移行希望の旨をご連絡ください。

WebPay ご連絡先: support@webpay.jp

PAY.JP ご連絡先: support@pay.jp または お問い合わせフォーム

定期課金について

WebPayのRecursions Objectを利用されている事業者の方は、上記カード情報に加え、定期課金の移行が必要になるかと思います。

定期課金については、WebPay・PAY.JP間の移行対象ではないので、事業者のシステム側で移行作業が発生いたします。

具体的な移行方法については、利用されているユースケースや決済規模によって、一概とはいえないため、個別サポートとさせていただきます。

WebPayとPAY.JPの定期課金対応表

WebPayとPAY.JPの定期課金の対応表を下記にまとめました。新規実装については、下記情報と両サービスのドキュメントを参考にしていただければと思います。

WebPay PAY.JP
関連Object Recursions Plan
Subscription
周期 月/年次 月次のみ
初回課金のスケジューリング recursion.first_scheduled に指定 subscription.trial_end に指定
月末課金日の挙動 前月の課金日に準ずる
e.g. 31日が課金日: 1/31 -> 2/28 -> 3/28
任意課金日( plan.billing_day )に準ずる
e.g. 31日が課金日: 1/31 -> 2/28 -> 3/31
Webhookの対応 有り 有り

定期課金 | WebPay: 開発者向けクレジットカード決済サービス

Webhook | WebPay: 開発者向けクレジットカード決済サービス

定期課金 - PAY.JP

Webhook - PAY.JP

審査について

WebPayをすでにご利用の方もPAY.JPのご利用には基本的に審査が必要となります。

審査は本番申請を受付後、下記の流れで行われます。

  1. 提携先カード会社によるVisa, MasterCard用の審査(最短2営業日程度)
  2. Visa, MasterCard用の審査結果のご連絡
  3. 「追加情報」の本番申請が済んでいる場合、JCB, American Express, Diners Club, Discoverの審査へ
  4. JCB, American Express, Diners Club, Discover用の審査(Visa, MasterCard用の審査可決後 15営業日程度)
  5. JCB, American Express, Diners Club, Discoverの各審査結果のご連絡
  6. 審査結果に基づきJCB, American Express, Diners Club, Discover用の各本番機能の提供

Visa・MasterCardに限り、審査が不要な場合がございますが、確認まで2営業日ほどのお時間をいただきます。

審査を進めていくにあたって、サービスの内容などについて追加情報や情報の修正を求める場合があります。また、カード会社の都合により、目安となるスケジュールから多少前後する可能性があります。

事業者のみなさまには大変ご迷惑をおかけいたしますが、よろしくお願いいたします。

PAY.JP 新規登録

PAY.JP 本番申請

移行に関する説明会・個別相談会

PAY.JPでは少しでも事業者のみなさまが負担なく、スムーズに移行ができるよう、11月18日(金)19:30~より「PAY.JPのサービス、ならびにWebPayからPAY.JPへの移行に関する説明会」を実施いたします。

このブログで紹介した内容に加え、WebPayとPAY.JPのAPIにおける細かい違いや注意点に関する説明を行う予定です。懇親会も予定しており、困っていることや疑問点をPAY.JPのメンバーに直接聞いていただくお時間も用意しております。

また説明会とは別で、オンライン通話などを用いて移行に関する「個別相談会」を継続的に実施していきたいと考えております。

1回20分程度のお時間で、appear.inやSkypeを利用したオンライン個別相談会を想定しておりますが、ご希望が御座いましたら対面での相談も可能でございます。

説明会、または個別相談会への参加をご希望の方は、下記申し込みフォームよりそれぞれお申込みください。

PAY.JP 説明会 申し込みフォーム

PAY.JP 個別相談会 申し込みフォーム

その他移行に関してご不明点などございましたら、メールFacebookメッセージ、またはお問い合わせフォームよりPAY.JPへご連絡ください。

[参考情報]

PAY.JP API リファレンス

PAY.JP API 利用ガイド - PAY.JP

WebPay サービス終了にあたっての PAY.JP への移行方法

@wozozo です。

日本の決済サービスの先駆けである WebPay からサービス終了のアナウンスがありました。

外苑前のオラクルで行われた pyfes というイベントでの @keikubo さんの日本の決済の話、決済代行会社との契約の話、個人でも使えるようになど、わかりやすい言葉で話されていたのを覚えています。

PAY.JP では、WebPay と連携して移行をサポートしていきます。

WebPay の API サービスは 2017年04月30日 23:59 まで継続されるので、停止までの6ヶ月間が移行期間になります。

ドキュメントについて

API について

PAY.JP では数多くの決済サービスと同じく、多くの互換性を保持しております。WebPay の組み込みをされていた方であれば特に迷うことなく PAY.JP の API もご利用可能です。

SDK について

PAY.JP では現在、Python, PHP, Node.js, Ruby, Java, Perl, Go 言語の SDK を用意しております。

SDK のない言語でも、API へのリクエスト自体は curl でも投げられる簡単なリクエストですので、どの言語からでも扱うことが可能です。

ご利用可能ブランドについて

WebPay では VISA / Master / Amex / JCB / Diners の5ブランド、PAY.JP ではそれに Discover を加えた6ブランドが利用可能です。

WebPay で現在決済サービスをご利用になられている方は、審査の上で現在の利用可能ブランドが提示されているかと思いますが、PAY.JP への移行の際にも再度審査が発生いたします。その審査の結果次第では、現在利用可能なブランド数よりも増える・減る可能性の両方が存在します。

決済ゲートウェイの移行

単発決済のみの場合 (Customer オブジェクトを利用されていない場合)

お客様のECサイトなどの会員情報等と WebPay 上の Customer オブジェクトを紐づけていない場合は、特にデータ移行作業の必要はありません。会員登録後に本番申請をしていただくだけでほぼ同じ API で PAY.JP への移行が可能です。

Customer や Recursion オブジェクト(定期課金) を利用されている場合

Customer や Recursion オブジェクトは WebPay 上にカード番号を保存して使用します。 PAY.JP への移行の際には、ここで保存しているカード番号も移行する必要があります。

WebPay と PAY.JP はともに、クレジットカードブランド5社が定めるセキュリティレベル「PCI-DSS」に完全準拠した運用を行っています。PAY.JPでは、PCI-DSS に準拠したセキュアな方法でWebPayからのカード番号の移行をサポートいたします。

これらの移行が必要な場合は、まずはお問い合わせフォームFacebookメッセージからお問い合わせください。個別にサポートさせていただきます。

PAY.JP プロプランでクレジットカード手数料2.59%に

PAY.JP では9月より従来のベーシックプラン

  • VISA / MasterCard 3.0%
  • AMEX / JCB / Diners Club / Discover Card 3.6%

に加えて、プロプラン

  • VISA / MasterCard 2.59%
  • AMEX / JCB / Diners Club / Discover Card 3.3%

の提供を開始しました。

料率以外の部分でも、ベーシックプラン入金サイクルは「月末締めの翌月末払い」の月1回ですが、プロプランの締めは「15日」と「月末」の月2回あり、入金もそれぞれの締め日からの半月後払いになっているので入金サイクルを早めることが可能です。

ベーシックプランとプロプランの違いをまとめたものが下になります。

f:id:payjp:20161026154533p:plain

月間流通額が少し伸びてきた際にはプロプランのほうが料率・入金サイクルともお得になりますのでご検討ください。

PAY ID OAuth API を導入する

こんにちは、PAYでエンジニアをしています @satetsu888 です。

前回の記事では、Checkoutを使ったPAY IDの導入についてご紹介しましたが、 今回はより自由な連携が可能になるPAY IDのOAuth APIについて、何ができるようになるのかの紹介と実際の導入について説明させていただきたいと思います。

PAY ID とは

PAY IDは、メールアドレスとパスワードだけで支払いができるようになる購入用のアカウントです。BASEや各事業者のWebサービスで導入されており、多くの支払いが行われています。

id.pay.jp

PAY ID OAuth APIで出来ること

現在「アカウント情報の取得」「カード情報の取得」「カード決済のためのトークン取得」「住所情報の取得」などの機能が提供されています。 (「カード情報の取得」ではカード番号下4桁やカードのブランドなど、利用カードの確認などにお使いいただける情報のみ取得できます。)

これらのAPIを活用することにより利用者がPAY IDでログインするだけで

  • ユーザの識別
  • カードによる決済
  • 商品配送先住所の取得

の3つが行え、特にEC系のサイトにおいて非常に快適な決済・購入体験を提供することができます。

BASEの事例

BASEのPAY ID連携ではOAuth APIが利用されています。

利用者は商品をカートに入れた後に「PAY IDで購入」を押し、メールアドレス/パスワードを入力してPAY IDにログインすることで f:id:payjp:20160907152346p:plain

PAY IDに登録してある決済情報や配送先住所が自動的に入力されるため、買い物のたびにカード番号や住所などを入力する必要がなく、快適に商品の購入が行えるようになっています。 f:id:payjp:20160907152403p:plain

PAY ID OAuth APIを使った実際の購入は http://shop.thebase.in/ やBASEで提供されている各店舗で体験可能です。是非お試しください。

OAth API の導入

OAuth APIの導入のためにOAuthクライアントの作成が必要となりますので、前回の記事の「1. OAuth Clientを作成する」と同じ手順でご用意ください。 Redirect URIについては、作成後も変更可能ですので仮のURIで作成していただいても問題ありません。

具体的なアプリケーションの実装について、下記のPHPによるPAY ID OAuth APIの簡単なサンプルコードを使って説明していきます。 https://github.com/payjp/payjp.github.io/tree/master/sample/pay-id-php

実際のアプリケーションの実装には、各言語で利用されているOAuthのライブラリ等を利用することをお勧めします。 また、各APIの詳細やOAuth API利用の流れ等の説明もありますのでリファレンスも合わせてご参照ください。

1. Authorization Endpointへのリンク作成

OAuth API利用の最初のステップとして「PAY IDで購入」などのボタンを押した利用者を、https://id.pay.jp/.oauth2/authorize に適切なクエリパラメータをつけたURLへと遷移させます。

サンプルコード100行目付近の処理をご参考ください。

https://github.com/payjp/payjp.github.io/blob/master/sample/pay-id-php/pay-id-sample.php#L99-L110

2. リダイレクトとToken Request

PAY IDのログインとアプリケーションのアクセス許可の同意を済ませた利用者は、codeパラメータとともにOAuthクライアント作成時に設定したRedirect URIへとリダイレクトされてきます。 Redirect URIの設定が仮になっている場合は、codeパラメータの処理するエンドポイントを作成後適切に設定してください。

ここで返って来たcodeパラメータを使って、トークンを取得するための Token Request を行います。

サンプルコード37行目から67行目の処理をご参考ください。

https://github.com/payjp/payjp.github.io/blob/master/sample/pay-id-php/pay-id-sample.php#L37-L65

3. トークンの取得とAPI呼び出し

Token Requestのレスポンスに含まれるaccess_tokenを使って、HTTPヘッダに Authorization: Bearer [access_token]を入れることでOAuth API のリクエストが行えます。

サンプルコード67行目から90行目では、「アカウント情報の取得」「カード情報の取得」「カード情報のトークン化」「住所情報の取得」のAPIを順番にリクエストしています。

https://github.com/payjp/payjp.github.io/blob/master/sample/pay-id-php/pay-id-sample.php#L67-L90

APIから取得したユーザの情報をアプリケーションでご利用いただき、スムーズな決済・購入体験を提供しましょう。

まとめ

今回はPAY ID OAuth APIの紹介と導入について簡単にですがご紹介しました。

OAuth APIの利用にはCheckoutに比べると少し実装のコストがかかるのですが、住所の自動入力もできることや、PAY IDにログイン済みのブラウザの場合は、メールアドレス/パスワードさえ入力しなくても良いという非常に快適な購入体験が可能になります。

PAY IDは提供開始から1ヶ月半で10万アカウントを突破し、その後も順調に利用者数が伸びています。この機会に是非PAY ID及びPAY ID OAuth APIを使ってみてください。

また、PAY.JP、PAY IDの導入について不明点などございましたらフォーラムでの質問やお問い合わせからご連絡いただければと思います。