- 自社の決済手段設定を読む — 自社アカウントについての同じ情報を、API から取得します。
- Payin 契約と取引上限 — 自社アカウントについての同じ情報を、Portal の表示で確認します。
- 決済手段の有効化 — 決済手段を自社アカウントに追加する方法。
対応している決済手段と市場の一覧はどこにありますか？
決済手段 にあります。テーブルには 3 つのフィルター — Type、Country/Region、 Subscription — と、次の列があります。
Country/Region フィルターが「どの市場をカバーしていますか？」への正本です — このページを含め、文章で書かれたどの一覧でもなく、
そこの現在の選択肢を読んでください。
2 つの市場コードは国ではありません。
インド、モロッコ、パキスタン、ロシアはカバーされていますか？
この 4 つの市場はいずれも公開カタログに掲載されていません。Country/Region フィルターにない他の市場も同様です。 その絞り込みに市場がなければ、その市場向けにカタログ登録されたものはなく、誰が尋ねても答えは変わりません。 同じ判定で逆の質問も解決します。市場がフィルターにあれば、それはカバーされています。お客様のアカウントが その市場で何かを契約しているかどうかは別の質問であり、カタログではなく 自社の設定 が答えます。1 行が複数の国と通貨をカバーしているのはなぜですか？
テーブルが表示前に集約しているためです。基になるカタログの行は市場、通貨、プロダクトごとに存在し、テーブルはそれらを 決済手段名 + タイプでグループ化し、グループを 1 行にマージします。
その結果は重要です。3 か国と Refundable: Yes を示す行は、3 か国すべてで返金できることを約束するものではありません。
楽観的なマージにより、テーブルが答えるのは*「これが当てはまることがあるか？」であって、「自分の市場で当てはまるか？」*
ではありません。市場ごと・通貨ごとの答えが必要な場合は、各契約が個別のエントリーとなっている自社アカウントの設定
エンドポイントを使用してください。
同じ決済手段に見える名前が 2 つあるのはなぜですか？
ウォレットの市場別バリアントは、別々の名前と別々の契約を持つ別々のカタログエントリーだからです。たとえばALIPAY と ALIPAYHK、WECHATPAY と WECHATPAYHK です。市場、決済通貨、そしてお客様のアカウントがどのエントリーを
契約しているかが異なります。
実務上のルール：
payMethodNameは、そのまま送信する値です。 購入者が認識する名前ではなく、カタログまたは自社の設定レスポンスから 取得してください。決済手段のチェックアウト表示名とpayMethodNameは、常に同じ文字列とは限りません。- 一方のバリアントを契約していても、もう一方を契約したことにはなりません。 契約していないバリアントを送信すると、
注文作成は
A0018で失敗します。よくあるエラーのトラブルシューティング を 参照してください。 - 同じ名前でも市場が異なれば同様です。複数の市場でカタログ登録されている 1 つの決済手段名でも、契約は市場ごとに 1 つです。
payMethodType のカテゴリーには何がありますか？
payMethodType は粗いカテゴリーで、固定の列挙型です。正確な payMethodName の代わりに注文作成時に送信すると、
購入者がカテゴリー内で選べるようになります。カンマ区切りで複数送信することもできます。
つづりに注意してください。カードのカテゴリーは 1 語の
CREDITCARD と DEBITCARD で、韓国国内カードは KOREANCARDS です。
CARD、BANK_ACCOUNT、WALLET という値は存在しません。
このうち 4 つのカテゴリー — VA、OTC、CREDITCARD、DEBITCARD — では、具体的な決済手段名を併せて指定する必要が
ありません。購入者がチェックアウトで具体的な選択肢を選ぶためです。それ以外のカテゴリーでは、購入者を意図的に Waffo の
チェックアウトへ送って選ばせる場合を除き、注文作成時に payMethodName が必要です。
Apple Pay と Google Pay は個別に有効化が必要ですか？
はい。これらは独自のカタログカテゴリー（APPLEPAY と GOOGLEPAY）であり、市場ごとに独自のカタログエントリーを持つため、
それぞれが独自の契約です。カードが稼働していても、これらが稼働することにはなりません。どちらも契約以外に連携作業が
必要であり、そのため独自の公開ガイドがあります：
Apple Pay と
Google Pay。
同じ論理が他のどの決済手段にも当てはまります。カタログエントリーごとに契約が 1 つで、有効化は
決済手段の有効化 の手順で行います。
ある決済手段が継続課金に対応しているかは、どう判断しますか？
単一の契約に「サブスクリプション対応」のフラグはありません。サブスクリプション対応は別のプロダクトとして表現されます。 カタログ行のproductName です。Payin のプロダクトは 4 つあります。
したがって、ある決済手段が継続課金で利用できるのは、
SUBSCRIPTION の下にその決済手段のカタログエントリーがある場合です。
公開テーブルではこれが Subscription 列であり、自社アカウントでは productName が SUBSCRIPTION である
payMethodDetails のエントリーです。
加盟店が頻繁に遭遇する 2 つの結果：
- ワンタイムとサブスクリプションは別々に有効化されます。 ある決済手段がワンタイム決済で稼働していても、自社アカウントで 継続課金に使えるようにはなりません。それは 2 つ目の契約です。
- 上記の集約ルールを思い出してください。公開テーブルの Subscription: Yes は、その決済手段の市場/通貨の組み合わせの 少なくとも 1 つがサブスクリプションプロダクトの下にあるという意味であり、すべてではありません。
決済手段は、購入者が Web にいるかアプリ内にいるかで変わりますか？
変わることがあります。コンテキストはuserInfo.userTerminal で宣言します。
何も送信しない場合のデフォルトは
WEB です。すべての決済手段がすべての端末をサポートしているわけではないため、この値は
注文で使用できる決済手段を変えることがあります。ウォレット内の 2 つの値については、任意のコンテキストではなく、
そもそも決済を成立させるための必須要素です。
カタログには決済手段ごとの端末マトリクスはありません。確実に知る方法は注文作成のレスポンスです。購入者が実際にいる端末を
送信し、その決済手段が使用できるかどうかをレスポンスに語らせてください。ある文脈で決済手段が現れず別の文脈で現れたことから、
端末の制限を推測しないでください。
payOption とは何ですか？ 各オプションを個別に有効化する必要がありますか？
payOption は決済手段の内部の副選択です。ウォレット残高からの支払い、デビットカードからの支払い、クレジットカードからの
支払いなどです。知っておくべきことが 2 つあります。
- 注文作成と照会では読み取り専用です。 購入者が実際に選んだものを報告し、選択肢のない決済手段では空で返されます。
- 契約上はオプションごとに料金設定されることがあります。 その場合、
Payin 契約ページ には決済手段ごとではなくオプションごとに手数料の行が
表示され、オプション間に意味のある区別がない決済手段は
-と表示されます。
カタログと自社の契約済み一覧はどう違いますか？
両者は異なる質問に答えており、これを混同することが「ドキュメントでは動くのに自分のアカウントでは動かない」の最もよくある原因です。
自社の一覧は常により狭いものであり、連携で分岐すべきなのはそちらだけです。公開カタログは「どの市場で有効化を依頼すべきか」を
検討するための計画資料として扱い、実行時の正本としては決して扱わないでください。
次にどこを見ればよいですか？
- 自社の決済手段設定を読む — 自社の設定レスポンスの全フィールドと、そこから生じるエラー
- 決済手段の有効化 — 決済手段が追加される仕組みと、各有効化ステータスの意味
- 決済手段の返金と上限 — 決済手段ごとの返金形式、返金期間、返金の最小金額
- チェックアウトの表示ルール — 契約済みの決済手段がチェックアウトでどのように並べられ、グループ化されるか
- 決済手段 — カタログそのもの