Charges API でのカード支払いレガシー
Stripe のレガシーの API を使用してカードに請求する方法や、カード情報を保存および認証する方法をご紹介します。
レガシーの API
The content of this section refers to a Legacy feature. Use the Payment Intents API instead.
Charges API は、以下の機能をサポートしていません。これらの多くはクレジットカードのコンプライアンスのために必要となります。
Charges および Tokens API は、デビットカードとクレジットカードでの決済を受け付けるために以前の Stripe システムで使用されていたレガシーの API です。新しいシステムでは、PaymentIntents を使用してください。
Charges API では、利用できる Stripe の機能は限られています。最新の機能を使用するには、Stripe Checkout を使用するか、または Payment Intents API に移行してください。
決済フロー
ほとんどの場合、PaymentIntents API はより優れた柔軟性と多くの組み込みオプションを提供します。
Charges API | Payment Intents API |
---|---|
|
|
返金
API を使用して支払いを返金するには、Refund (返金) を作成し、返金対象の支払いの ID を指定します。
支払いの一部のみを返金するには、セント単位の整数で (または最も小さな支払い通貨単位で)、amount
パラメータを指定します。
Apple Pay
顧客が支払いを承認すると、お客様のアプリは、PKPaymentAuthorizationViewControllerDelegate メソッドを実装することにより、顧客の暗号化されたカード詳細が含まれた PKPayment インスタンスを受け取ります。
- createTokenWithPayment SDK メソッドを使用して、
PKPayment
を StripeToken
にします。 - この
Token
を使用して支払いを作成します。
動的な明細書表記
デフォルトでは、Stripe アカウントの明細書表記は、カードに請求するたびに顧客の明細書に表示されます。また、Charge オブジェクトの statement_
引数を使用すると、請求リクエストごとに明細書表記を動的に設定することができます。
明細書表記は最大 22 文字で、特殊文字 <
、>
、'
、"
または *
は使用できません。また、数字だけにすることもできません。
クレジットカードおよびデビットカードの支払いに明細書表記を動的に設定すると、動的な部分が売上処理加盟店の明細書表記に追加されます (*
と空白で区切られます)。たとえば、購入されたクッキーの種類が含まれる、FreeCookies という名前のビジネスの明細書表記は、FREECOOKIES* SUGAR
のようになります。
*
および空白も 22 文字の制限に含まれ、Stripe は自動的に動的明細書表記に 10 文字を割り当てます。よって、売上処理加盟店の明細書表記が 10 文字よりも長い場合には短縮される可能性があります (動的な明細書表記も 10 文字を超えると仮定した場合)。動的な明細書表記も 10 文字を超える場合には、両方の表記が 10 文字で切り詰められます。
文字制限で問題が生じている場合には、Stripe ダッシュボードで短い表記を設定して売上処理加盟店の表記を短くできます。これにより動的な明細書表記の文字数に余裕がでます。短い表記は以下の役割を持ちます。
- 動的な明細書表記を使用する場合に、売上処理加盟店の明細書表記を置き換えます。
- 2 ~ 10 文字の間にできます。
注
アカウントの明細書表記が 10 文字を超える場合には、ダッシュボードで短い表記を設定するか、statement_
を使用します。これにより、予想外の形式で明細書表記が切り詰められることがなくなります。
明細書表記が全体としてどのように表示されるかは、Stripe ダッシュボードで確認できます。
メタデータに情報を保存する
Stripe では、支払いの処理など、一般的なリクエストにメタデータを追加することをサポートしています。メタデータは顧客に対して表示されたり、不正利用防止システムによる支払いの拒否やブロックの要因として考慮されたりすることはありません。
メタデータを使用して、その他の情報 (お客様にとって意味のある情報) を Stripe アクティビティーに関連付けることができます。追加したメタデータはすべてダッシュボードで確認でき (個々の支払いのページを表示するときなど)、一般的なレポートやエクスポートで使用することもできます。一例として、お客様のストアの注文 ID を、その注文の支払いに使用された請求に関連付けることができます。このようにすると、お客様、お客様の会計士、または財務チームが、Stripe での請求をお客様のシステム内の注文と簡単に照合できるようになります。
Radar を使用している場合、メタデータとして追加の顧客情報や注文情報を渡すことを検討してください。このようにすると、メタデータ属性を使用して Radar ルールを記述して、ダッシュボードで支払いに関するより多くの情報を確認できるため、審査プロセスの効率化につながります。
注意
機密情報 (個人が特定される情報、カード詳細など) は、メタデータや支払いの description
パラメーターに保存しないでください。
支払い拒否
組み込みが支払いの失敗に対して自動的に対応するようにしたい場合は、2 つの方法で支払いの outcome
にアクセスできます。
- 支払いが失敗したときに返される API エラーを処理します。ブロックされ、カード発行会社に拒否された支払いの場合、エラーには支払い ID が含まれ、これを使用して支払いを取得できます。
- Webhook を使用して、ステータスの更新を監視します。たとえば、
charge.
イベントは、支払いが失敗したときにトリガーされます。failed