顧客のデフォルトカード以外で支払いを作成できるようになりました

PAY.JPでは日々機能の追加を行なっています。今回はたくさんご要望をいただいていた「顧客のデフォルトカード以外を使っての支払い作成」ができるようになりましたのでお知らせします。

今まで顧客に対して複数のカードを登録している状態でデフォルトカード以外で支払いを行うには、まず最初に顧客のデフォルトカードを変更していただき、その後に支払いを作成するという2つのステップが必要でした。 これからはCharge APIを利用する際にcustomerに顧客ID、cardに顧客に登録されているカードIDを同時に指定することで、デフォルトカードの変更をせずに支払いに使うカードを指定できます。

例えば顧客ID cus_paykun に登録されているデフォルトカードとは別のカード car_paykun_2nd_card で支払いを作成する場合は、下記のようなリクエストを行います。

curl https://api.pay.jp/v1/charges \
-u sk_test_c62fade9d045b54cd76d7036: \
-d customer=cus_paykun \
-d card=car_paykun_2nd_card \
-d amount=100 \
-d currency=jpy

ライブラリを利用する場合も同様にCharge作成時にcustomercardのパラメータを同時に指定してください。

payjp-go をご利用いただいている場合のみ、この形式のリクエストを行うためのアップデートがありますので、必要に応じてライブラリのアップデートをお願いいたします。

サンプルを使ってPAY.JPのオンライン決済を学ぶ

PAY.JPではJavaScriptを使ってクレジットカード番号の一時的トークンを生成して決済する仕組みがあります。シーケンス図で表すと次のようになります。

f:id:goofmint:20171108144326p:plain

この仕組みを使った利点としては、サービス事業者(ECサイトを運営している企業など)がクレジットカード番号を知らずにオンライン決済を提供できることです。クレジットカード番号が事業者のサーバを通過する仕組みを提供する場合、2018年3月までにPCI DSSの対応が必要になります。これはセキュリティ基準としてハードルが非常に高いです。

PAY.JPのチェックアウトを使う場合、クレジットカード番号が事業者のサーバを通過せずに済むので、PCI DSSの対応が求められず、安全かつ簡単に決済を導入することができます。今回はRuby/Sinatraを使ったサンプルを基に、実装方法を紹介します。

決済画面を表示する

まず最初に決済を行う画面を表示します。この時必要になるのはPAY.JPの公開キーです。これは設定画面のAPIキーの中で確認できます。これを下記HTMLの YOUR_PUBLIC_KEY と書き換えます(コード1)。

<form action="/pay" method="post">
  <article>
    <label>1000円のお支払い</label>
  </article>
  
  <script class="payjp-button"
    src="https://checkout.pay.jp/"
    data-key="YOUR_PUBLIC_KEY">
  </script>
</form>

コード1

f:id:goofmint:20171108144507p:plain

なお、formタグの /pay は自社のWebサイトの決済処理用のURLになります。

この状態でWebページを表示すると カードで支払う ボタンが表示されます。

f:id:goofmint:20171108144526p:plain

PAY.JPでの処理

そしてボタンを押すとモーダルでPAY.JPの決済フォームが表示されます。テストで行う場合にはテストカード | PAY.JPからテスト用のクレジットカード番号を選んでください。テストの場合、有効期限やCVC、名前は適当で問題ありません。

f:id:goofmint:20171108144539p:plain

そして処理が完了すると、フォームのイベントである POST /pay がすぐに呼ばれます。

サーバでの処理

PAY.JPでクレジットカード番号からトークンに変換されると、その情報は payjp-token という名前でPOSTされてきます。そのまま使うこともできますし、今後繰り返し使っていくのであれば顧客情報と結びつけることもできます。

以下は顧客情報と結びつける場合です。

customer = Payjp::Customer.create(
  :email => 'example@pay.jp',
  :card  => params['payjp-token']
)

レスポンスであるcustomer.idを自社のデータベースに保存しておきます。こうするとトークンが繰り返し使えるようになります。

実際の決済処理は次のようになります。トークンではなく、customer.id を指定しているのが特徴です。

amount = 1000
Payjp::Charge.create(
    :amount => amount,
    :currency => 'jpy',
    :customer => customer.id,
    :description => '決済に関する説明'
)

例えばECコマースのユーザ情報と結びつけることで、二度目以降はクレジットカード番号の入力を不要にできます。

なお、このSinatraのサンプルコードはpayjp/payjp-exampleにアップロードされています。実装時の参考にしてください。

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

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メッセージからお問い合わせください。個別にサポートさせていただきます。