MevvPos — Mevvsoftドキュメント

インストール

MevvPosにはWordPress 6.0以上とPHP 8.1以上が必要です。WooCommerceは必須ではありません。WooCommerce 9.0以降が有効な場合、MevvPosは自身をチェックアウトの支払い方法として登録します。WooCommerceがなくても決済エンジンは読み込まれ、他のプラグインから動かすことができます。以前のバージョンではWooCommerceが必須の依存関係とされており、それがないとWordPressは有効化を拒否していましたが、その要件はなくなりました。

WooCommerce の二つの決済画面のどちらにも対応します。MevvPos は従来のショートコード決済ページにも、新しい決済ブロックにも自身を登録します。4.7.1 までは従来ページにしかつながっておらず、ブロック決済に移行した店舗ではカード決済の選択肢がまるごと消えていました——エラーも警告もなく、ただ支払い方法が欠けるだけです。追加の設定は不要で、ブロックページでもカード入力欄、分割払い表、分割払い手数料が同じように表示されます。

プラグイン → 新規追加 → プラグインのアップロードからプラグインをアップロードし、有効化します。
管理画面の左メニューから MevvPos を開きます。WooCommerce の下にもショートカットがあります。決済設定を探すとき、多くの方がそちらを見るからです。
一般タブで支払い方法を有効にし、購入手続きで顧客に表示されるタイトルを設定します。
Bank APIタブで、プロバイダー（トルコの銀行仮想POSか、5つの国際プロバイダーのいずれか）を選び、そのプロバイダーから渡された認証情報を入力します。
国際プロバイダーを選んだ場合は、同じタブに表示されているWebhookアドレスをコピーし、プロバイダー自身の管理パネルに貼り付けてください。これがなければ何も完了しません。
分割払いと手数料で分割払いの料率を入力します。
本番稼働の前に、銀行のテスト用認証情報で動作を確認してください。

The free plugin creates no database tables and registers no scheduled job. Everything lives in WordPress options and in order meta.

Pro は無料版と並べてインストールする別のプラグインであり、無料版の置き換えではありません。無料版は WordPress.org で公開されており、そこで公開されたものはすべて GPL のもとで再配布できます。有料のソースコードを同じパッケージに入れていれば、ライセンス確認を削除した人が法的に再配布できてしまいます。ライセンスキーはライセンスタブで入力します。

WooCommerce → 設定 → 決済 → MevvPos を開くと、MevvPos の画面へ転送されます。これは意図的です。この設定の置き場所は一つであるべきで、食い違いうる二つがあってはならないからです。

仕組み

MevvPosは2種類の決済プロトコルを扱い、どちらになるかは選んだプロバイダーによって決まります。どちらも同じエンジンを通り、同じ注文レコードを生成します。

署名付きフォーム——トルコ: 7つのトルコ仮想POSファミリー。MevvPosが決済フィールドを組み立て、ストアキーで署名し、銀行にPOSTします。顧客は3-D Secureで認証し、銀行はサイトに戻ってきます。その戻り時の署名が注文を完了させるものです。
ホスト型ページとWebhook——国際: Stripe、PayPal、Mollie、Square、Authorize.Net、Checkout.com、Razorpay、Paystack です。MevvPos は各社の REST API 経由でプロバイダー側に決済を作成し、顧客をプロバイダー自身のページへ送ります。注文を完了させるのはプロバイダーからの応答です——webhook アドレスに届く署名付き通知か、あるいは（それが届く前に顧客が戻ってきた場合は）戻りページから行うサーバー間のステータス照会です。単独で注文を完了させることが決してないのは、ブラウザーの戻りです。

トルコ側では、エンジンは国際プロバイダーには決して必要とされないことを行います。それは、あなたのどのアカウントがそのカードを扱うかを決定することです。

POS レコードを一つ以上定義します。POS レコードとは、ある銀行のバーチャルPOS 一つ分です。認証情報、ゲートウェイのアドレス、分割払いの料率をまとめたものです。
購入手続きで、お客様がカード情報を入力します。最初の 6 桁 — BIN — から発行銀行が特定されます。
MevvPos は BIN を照会し、その銀行にお客様の POS があれば、支払いをその POS へ送ります。無ければ、既定の POS が受け持ちます。
分割払いが提示されるのは、そのカードが当該 POS の銀行のものである場合だけです。銀行は他行のカードに分割払いを認めないからです。
お客様は銀行側で 3-D セキュアを通過し、銀行はお客様のサイト上にある一つのコールバックアドレスへ戻します。
戻り値の署名は、その注文が実際に使った POS の鍵で検証され、注文が完了し、結果が記録されます。

カード番号、有効期限、CVV が、データベースや WooCommerce のセッションに書き込まれることはありません。保持されるカード関連の情報は、最初の 6 桁と、判定された銀行名だけです。

5つの国際プロバイダーでは、カードデータはサイトに一切届きません。カードはプロバイダー自身のページに入力されます。これが、PCI適用範囲を小さく抑える最短の経路である理由であり、同時にBINルーティングも分割払いも持たない理由でもあります。

国際プロバイダー

国際プロバイダーは Türkiye 以外の地域をカバーします。いずれもプロバイダー自身のホスト型またはリダイレクト型のページを使うため、カード情報がお客様のサイトに入力されることはありません。認証もそこで行われますが、結果はそこに置き去りにされません。MevvPos は支払者が認証されたかどうかを記録し、発行会社が追加認証を求めた場合は銀行へ送り、ECI を読んでチャージバックの責任が移転したかどうかを記録します。プロバイダーが結果を通知しない場合は、貴社の責任としてではなく「不明」として記録します。カード以外の地域別の支払い方法も、各プロバイダー自身の項目で送られます。iDEAL、Bancontact、SEPA ダイレクトデビット、Klarna、EPS、Przelewy24、BLIK、TWINT、Multibanco、ウォレット。どれを提供するかはアカウントごとにお客様が選び、選ばなかった方法が送られることはありません。注文の通貨に合わない方法はその場で除外されます。ドル建ての注文に iDEAL を提示しても、プロバイダー側で決済が失敗するだけだからです。

Stripe: mode=paymentのCheckout Sessionを使用し、Stripe自身のページの裏側でPayment Intentを作成します。シークレットキーは加盟店キーに、Webhook signing secretは追加フィールドに入力します。注文は署名済みのpayment_intent.succeededによって完了します。Elementsは意図的に使用していません。使用するとカードフィールドがあなたのページに移動し、PCI適用範囲が広がってしまうためです。
PayPal: Orders v2を3段階で使用します：注文を作成し、顧客がPayPalで承認し、MevvPosがキャプチャします。見落としやすいのは3番目の段階です——承認されたのにキャプチャされない注文は、見た目は支払い済みでも実際には入金されないままになります。REST クライアントIDは加盟店番号に、クライアントシークレットは加盟店キーに、Webhook IDは追加フィールドに入力します。
Mollie: Payments API v2を使用します。APIキー——live_…またはtest_…——は加盟店キーに入力します。Mollieは通知に署名しないため、追加フィールドはありません。MevvPosが代わりに何を行うかは、下のWebhookのセクションを参照してください。
Square: Checkout API経由のPayment Linkを使用します。アクセストークンを加盟店キーとして入力し、Location IDとWebhook signature keyも入力します。Squareはすべての売上をロケーションに紐づけます。Location IDがなければ決済自体を作成できませんが、Square自身のエラーはそのことをはっきりとは示しません。
Authorize.Net: Accept Hostedを使用します。API Login IDは加盟店番号に、Transaction Keyは加盟店キーに、Signature keyは追加フィールドに入力します——Signature keyはTransaction Keyとは別の値で、混同しやすいので注意してください。これはリダイレクトアドレスを返さない唯一のプロバイダーです。代わりにトークンを返し、MevvPosはそのトークンをフォームとしてホスト型ページにPOSTします。
Checkout.com: Hosted Payments Page です。シークレットキー（sk_…）は加盟店キーに、webhook 署名キーは追加フィールドに入れます。通知は生のボディに対する HMAC-SHA256 で署名されます。想定しておくべき挙動が一つあります。返金は非同期で受理されます。Checkout.com は返金呼び出しに 202 とアクション ID を返しますが、これは要求が受理されたという意味であって、返金がすでに完了したという意味ではありません。
Razorpay: Payment Link です。インド向けに販売する店舗のためのもので、現地ではカードだけでは足りず、UPI、ネットバンキング、ウォレットがプロバイダーのページにまとめられています。Key ID は加盟店番号、Key Secret は加盟店キー、webhook シークレット（Key Secret とは別の値）は追加フィールドに入れます。Razorpay は二つの識別子を返しますが、これらは交換できません。ステータスの照会にはリンク ID（plink_…）を使い、返金は、支払い後にリンクが報告する決済 ID（pay_…）でしか行えません。
Paystack: ホスト型の取引ページです。ナイジェリア、ガーナ、南アフリカ、ケニア、コートジボワール向けに販売する店舗のためのもので、これらの地域では USSD、銀行振込、モバイルマネーがカードと同じくらい重要です。シークレットキー（sk_live_… または sk_test_…）は加盟店キーに入れ、追加フィールドはありません——通知は同じシークレットを使って HMAC-SHA512 で署名されます。すべては単一のリファレンスにぶら下がっています。決済の開始も、ステータスの照会も、返金も、いずれもこれを使います。

テストモードは、PayPal、SquareおよびAuthorize.Netではプロバイダー自身のサンドボックスアドレスに切り替わります。StripeとMollieでは本番とテストをアドレスではなくキーで区別しているため、そこでは貼り付けたキーが決め手になります。

金額は最初から最後まで、その通貨の最小単位（クルシュ、セントなど）の整数として扱われ、小数として扱われることは決してありません。小数の文字列を求める唯一のプロバイダーはMollieで、その通貨に対して正確な桁数を要求します。10.0は拒否され、10.00は受け入れられます。この文字列は浮動小数点数ではなく整数から生成されます。

八社のいずれも、実際の加盟店アカウントで端から端まで検証されてはいません。各プロバイダーのファイルは、そのことを自身のヘッダーに明記し、どのドキュメントページをもとに書かれたかを列挙しています。処理の流れは各社の公開ドキュメントに従い、署名アルゴリズムとフィールド名もそこに固定してあります。しかしそれは完了した実決済と同じではなく、同じであるかのようには書きません。本番で実証済みではなく、ご自身のサンドボックスに接続して試せる状態、と読んでください。

POS レコード

POS のバーはタブの上にあり、どのタブでも表示されます。各カードには、銀行、加盟店番号、そして注意が必要なときにはバッジが表示されます。

既定: より適した対応先が見つからないときに支払いを受け持つ POS です。常にちょうど一つ存在します。
無効: 残してあるが、決済は受け付けない状態です。POS の設定は済んでいるものの、銀行側でまだ稼働していないときは、削除ではなくこの状態にしてください。そうしないと、その銀行のカードをお持ちのお客様が支払えなくなります。
ライセンス待ち: レコードは存在しますが、ライセンスが有効でないため休止しています。何も削除されておらず、ライセンスを更新すれば、止まったところから再開します。
API 情報が入力されていません: そのレコードには、まだ加盟店番号が入力されていません。

銀行はロゴではなく、色の帯で示します。銀行のロゴは商標であり、15 行分ともなれば法的な危険と、終わりのない保守の両方を抱え込むことになります。どの銀行がご自身のものかは、すでにご存じのはずです。

最後の POS は削除できず、最後に有効になっているものは無効にできません。カード決済を完全にやめるには、代わりに一般タブで支払い方法をオフにしてください。

There is no cap on the number of provider accounts, and routing between them — by the card’s issuing bank and by the order’s currency — is part of the free plugin. Earlier releases allowed one account; that limit was removed in 4.9.0.

ライセンスが切れたとき、決済を続けるアカウントはランダムに選ばれるわけではありません。デフォルトとしてマークされたアカウント、それがなければ設定済みの有効なアカウントの中で最初のものが選ばれます。ランダムに選ばれるとしたら、ある朝突然、店舗が別の銀行を通じて静かに決済を始めていた、ということになりかねません。

銀行 API — 認証情報とゲートウェイのアドレス

プロバイダー: 一覧はTürkiye——銀行仮想POSとInternational payment providersの2グループに分かれています。フォームがこの後に尋ねる内容はすべて、この1つの選択から決まり、その選択に適用できない設定はそもそも表示されません。
銀行: その POS を開設している銀行を選びます。ゲートウェイのアドレスも、分割払いに使う BIN リストも、この選択に従います。まだ実装のない金融機関は「— yakında」(近日対応) と表示され、選択できません。
加盟店番号 (Client ID): 銀行から渡された加盟店番号です。
加盟店キー (Store key): 加盟店のセキュリティキーです。パスワード欄として保存され、保存後はマスク表示されます。
Gate URL: 決済フォームの送信先アドレスです。
注文自体の通貨を銀行に送る: トルコの仮想POSのみに関わる設定で、初期状態ではオフです。複数通貨契約を結んでいない限り、MevvPosはトルコリラを送信します。これは銀行が想定している通貨です。通貨は署名の一部であるため、銀行が受け付けない値は説明なしに拒否されます。国際プロバイダーは注文の通貨をそのまま受け取るため、この設定を尋ねられることはありません。
テストモードをオンにする: 自動転送を止め、送信前にリクエストの内容を確認できるようにします。

保存時に Store Key を空欄のままにすることは、「変更しない」という意味です。空の値を書き込めば鍵が消え、エラーメッセージ一つ出ないまま、ストアは決済を受け付けなくなります。他の秘密情報の欄にも同じ規則が適用されます。

一部のファミリーは追加の認証情報を必要とし、フォームは選んだプロバイダーに対してのみそれらを表示します。

Garanti BBVA — Merchant ID、認証ユーザー名、認証パスワード。
VakıfBank — Terminal No (端末番号) と MPI のアドレス (空欄にするとテスト用アドレスが使われます)。
PayTR — Merchant Salt。
iyzico、Craftgate、Sipay — 追加の項目はありません: API キーを加盟店番号に、シークレットを加盟店キーに入力します。
Stripe——Webhook signing secret。
PayPal——Webhook ID。
Square——Location IDとWebhook signature key。
Authorize.Net——Webhook専用のSignature key。
Mollie——追加フィールドなし：APIキーはMerchant keyに入力します。

これらの追加の認証情報は署名に組み込まれます。一つでも欠けていると、署名は空の値で計算され、銀行は黙って決済を拒否します。エラーもメッセージも出ず、ただ拒否されるだけです。

NestPay 系の 7 行については、銀行の選択からゲートウェイのアドレスが自動的に入るため、Gate URL は空欄のままで構いません。それ以外では自動入力されないので、銀行または決済事業者から渡されたアドレスを入力してください。入力しないと、決済フォームの送信先がありません。

対応している 13 の金融機関

NestPay / Asseco (Payten): İş Bankası、Akbank、Halkbank、QNB、Şekerbank、TEB、Ziraat Bankası
Garanti GT3D: Garanti BBVA
PayFlex V4: VakıfBank
決済事業者: iyzico、PayTR、Craftgate、Sipay

実装のない金融機関は「— yakında」と付けて意図的に銀行リストに残してあります。取り除いてしまうと、どのプロトコル系統がまだ未対応なのかが見えなくなります。お使いの銀行がその一つであれば、銀行リクエストタブでお知らせください。

銀行自身が公開している例に照らしたゴールデンベクターのテストがあるのは、NestPay の署名だけです。それ以外の事業者は、ソースコード上で beta と記されています。処理の流れはドキュメントどおりに実装してありますが、その金融機関の実際の加盟店アカウントで端から端まで検証できてはいません。検証が済むまで、この表示は外しません。

決済事業者はカードを発行しないため、BIN リストを持ちません。振り分け先としてではなく、ご自身の POS として選択します。

Webhook——注文が実際に完了する場所

すべての国際プロバイダーはサイト上に1つのアドレスを必要とし、その形式はどのプロバイダーでも同じです。ホームアドレスに?mevvpos-webhook=<provider>を付加した形です。正確な値はBank APIタブに読み取り専用で表示されており、フィールドをクリックすると選択されます。

注文を完了させるのはWebhookであり、顧客がサイトに戻ってくることではありません。戻りアドレスは推測可能で、顧客は支払いをしていなくてもそこに到達できるため、ブラウザがそこに到達したこと自体は何も証明しません。MevvPosは戻りから結果を読み取ることは決してなく、署名付き通知を待つか、サーバー間でプロバイダーに直接問い合わせます。この2つの回答のどちらかが届くまで、注文は保留のままとなり、注文ノートにその旨が記録されます。

Bank APIタブからアドレスをコピーします。
Mollieは例外で、どこにも何も貼り付ける必要がありません。MevvPosは作成する決済ごとにアドレスを送信します。サイトがローカルアドレスで応答している場合、このアドレスの送信は省かれます。どのみちMollieはそこに到達できないためです——ローカル開発中は、代わりにステータス照会から結果が得られます。
表示されているとおり正確にプロバイダー自身のパネルに貼り付けてください。Squareは通知アドレスと本文をあわせて署名を計算するため、1文字でも違う——末尾のスラッシュ1つでも十分です——とすべてのイベントが検証に失敗し、しかもそれは静かに起こります。
プロバイダーが返す署名シークレットを、そのプロバイダーの追加フィールドに保存します。
プロバイダーのパネルからテストイベントを送信し、注文が実際に動くことを確認します。

Mollieは通知に一切署名しません——本文には支払いIDしか含まれていません。これは一見安全でないように見えますが、実際にはより安全です。MevvPosは通知を信用せず、それを呼び鈴として扱います。IDを受け取り、その支払いのステータスをMollieに直接問い合わせ、paidという回答が返ってきた場合にのみイベントを発生させます。攻撃者は架空のIDで呼び鈴を鳴らすことはできても、Mollieの回答を偽造することはできません。したがって偽の通知によって注文が支払い済みになることは決してありません。Mollieに到達できない場合、回答は「わからない」となり、何も変わりません。

PayPalの署名もローカルでは検証されません。これは証明書チェーンであり、チェーンの検証における気づかれないミスは署名を無意味にしてしまいます。PayPalはこれ専用のエンドポイントを公開しており、SUCCESS以外の応答はすべてイベントの無視を意味します。

どのプロバイダーにも3つのルールが共通して適用されます。応答は常に空の200です——検証済みのイベントも、重複したイベントも、でたらめな内容も、すべて同じ応答を受け取ります。応答を変えると、攻撃者にどの推測が近かったかを教えてしまうことになり、エラー応答を返すと、決して検証できないイベントをプロバイダーが再送し続けるだけになるからです。唯一の例外はPayTRで、文字どおりOKというテキストを求め、それがないと通知を何時間も繰り返します。同じイベントが2回届いても2度目の効果はありません。そして、あるイベントがどのアカウントに対して検証されるかは、リクエストからではなく常に自分自身の設定から読み取られます。そうしないと、攻撃者は自分の偽造がどの鍵で検証されるかを自分で指定できてしまいます。

WebhookはWooCommerceのエンドポイントを経由しません。独自のクエリ変数を持ち、テーマ、ページ、クエリの仕組みが動く前に捕捉されます——これは、WooCommerceがインストールされていないサイトでも動作する理由でもあります。

BIN による振り分け

カードの最初の 6 桁が、発行銀行を示します。MevvPos は、まさにその 6 桁で照合します。

A snapshot of the BIN table ships inside the plugin — 1.449 BINs across 36 banks in the current build — so routing works offline, with no account of any kind, from the moment you install it.
Pro 版では、当社サーバーから毎週更新されます。この更新は同梱の表を置き換えるのではなく、上書きして統合します。不完全な応答や空の応答によって、ストアが BIN データを一切持たない状態に陥ってはならないからです。
BIN が 100 件に満たない応答は、あり得ないものとして拒否され、書き込まれません。
同じ BIN を二つの銀行が主張するような衝突は、一覧を送る前に当社側で解決します。ストア側で解決させると、あるカードを「自行のもの」と数えながら、同時に別の先へ振り分けてしまうことが起こり得ます。

認識できない BIN が拒否されることはありません。既定の POS へ回されます。単に記録が無いだけのカードを断ることは、参照表を守るために売上を捨てるのと同じです。

同じ表は、購入手続きの場でもう一つ別の問いにも答えます。このカードは、この POS の銀行のものか? という問いです。分割払いを提示するかどうかは、これで決まります。詳しくは以下をご覧ください。

BIN の正確さは有料の機能ではありません。Pro 版で対価を払う対象は正確さではなく、新しさです。同梱の一覧は同じ一覧であり、ビルド時点で固定されているだけです。

分割払いと手数料

料率は POS ごとに、一括払いから 12 回払いまで分割払いと手数料タブで設定します。パーセントで指定します: 5.5% なら 5.50 と書きます。

これは二つの決済画面のどちらでも機能します。ブロックページでは分割払い表をブロック自身が描画し、手数料は従来ページとまったく同じようにカートへ料金として加算されます。したがって分割回数を選ぶと、注文確定前に合計が更新されます。

分割払いはトルコ固有の制度であり、このタブはそれを踏まえています。国際プロバイダーが選択されている間は料率表がまったく表示されず、代わりにタブは一文でその旨を説明します。決して適用されることのない12行を埋めさせることは、あなたを誤解させる方法になってしまいます。

0: その選択肢は表示され、手数料は加算されません。
空欄: その選択肢はまったく表示されません。空欄とゼロは、同じではありません。

手数料は、「N Taksit Komisyonu」(N 回払い手数料) という課税対象の料金としてカートに表示され、送料と税を含むカート合計をもとに計算されます。

分割払いが提示されるのは、その POS の銀行が発行したカードだけで、これはサーバー側で強制されます。画面上で隠しているだけではありません。他行のカードは一括払いに戻され、手数料も取り消されます。

The ceiling is twelve in every installation — that is the limit the banks themselves apply, not a product limit. It is enforced in three places: the list the customer sees, the value that arrives with the form, and the value the engine sends to the provider. A modified form cannot buy more instalments than you offer.

設定フォームは、ライセンスに関わらず常に 12 個すべての項目を表示します。ライセンス失効時に項目が消えていたら、ページを保存するだけで、すでに入力済みの料率が黙って削除されてしまいます。上限を超える項目には「Pro で利用可能」と表示され、入力された数値はそのまま保持されます。

銀行から提供される分割払いの表はありません。料率はお客様が入力したものであり、過去の注文の手数料は、その売上が立った日に適用されていた料率で計算されます。今日料率を変えても、昨日のレポートが書き換わることはありません。

決済の流れとカードの取り扱い

トルコの各系統はすべて 3-D Secure を通ります。3D なしのモードはなく、無効にする設定もありません。国際側では MevvPos が EMV 3-D Secure 2 に対応します。支払者が追加認証ありで認証されたか、なしで認証されたかを記録し、発行会社が追加認証を求めた場合は顧客を銀行へ送り、ECI を読んでチャージバックの責任が移転したかどうかを記録します。あえて行わないことが二つあります。プロバイダーに該当する項目がない免除を要求することは決してなく、プロバイダーが結果を通知しない場合に責任を貴社のものとして記録することもありません。「わからない」と「責任は加盟店にある」は別の答えです。

フォーム方式: NestPay、Garanti、PayTR、Sipay: ブラウザが署名済みのフォームを銀行へ送信し、お客様が認証を行い、銀行がサイトへ戻します。
サーバー方式: VakıfBank、iyzico、Craftgate: サーバーが事業者と通信して 3-D の画面を受け取り、それを表示し、認証後にサーバー間で決済を完了します。
リダイレクトフロー: Stripe、PayPal、Mollie、Square、Checkout.com、Razorpay、Paystack: MevvPos はプロバイダーの REST API 経由で決済を作成し、プロバイダーが返したアドレスへ顧客を送ります。
トークンフォームフロー: Authorize.Net：プロバイダーはアドレスの代わりにトークンを返し、そのトークンはフォームとしてホスト型ページにPOSTされます。トークンをURLに書き込むと、ブラウザの履歴やサーバーログに漏れてしまいます。

トルコの銀行は常にサイト上の1つのアドレスに戻ってきます：?wc-api=mevvpos_callback。その戻り時の署名は、注文が実際に使用したPOSの鍵——注文自体に記録されています——で検証されます。複数のPOSがある場合、誤った鍵で検証するとすべての決済でハッシュエラーが発生します。

カード情報がデータベースに届くことはありません。転送のあいだだけブラウザに保持され、その後は削除されます。支払いページの読み込み時にそれが無い場合 — 新しいタブ、再読み込み、ストレージの無効化、銀行からの戻る操作 — は、空の項目を銀行へ送るのではなく、カード入力フォームを表示します。カードフォームが既定で表示されているのは意図的です。決済の流れが、JavaScript が動いたことを前提にしてはならないからです。

銀行が決済を承認した場合、3-D のステータスコードが想定外であっても、注文は完了します。注文メモにその異常が記録され、銀行自身の画面で確認するよう促されます。銀行が承認したと言うなら、お客様はすでに課金されています。それを拒否すれば「カードは課金されたのに注文は失敗した」という事態になります。

決済の試行ごとに、使用した POS、カードの銀行と BIN、分割回数と料率、結果、銀行の応答コードとメッセージ、そしてオーソリと取引の参照番号が記録されます。

事前与信、支払いリンク、リスクルール

今すぐ与信、後で確定

各POSレコードは回収方法を持ちます — 即座に請求するか、金額を保留して後で回収するかです。後者の場合、チェックアウト時にカード上に金額が確保され、注文画面に2つのボタンが追加されます — 確定(全額または一部)と保留解除です。荷物が発送されるときに確定し、供給できない場合は保留を解除します。

この設定が表示されるのは、決済プロバイダーが実際にそれをサポートしている場合のみです — NestPay銀行グループ(İşbank、Akbank、Halkbank、QNB、Şekerbank、TEB、Ziraat)に加え、Stripe、Authorize.Net、Checkout.comです。それ以外のすべてのプロバイダーでは、選択肢が提示されて後でゲートウェイで失敗するのではなく、そもそも提示されません。

支払いリンク

支払いリンク画面では、金額を指定し、任意で説明と有効期限を付けてリンクを作成できます。リンクを開いた人は、すでに作成された保留中の注文とともにストアの通常のチェックアウトに移動します。つまり、他の決済と同じBINルーティング、同じ分割払い表、同じ3-Dセキュアのステップが適用されます。決済エンジンを迂回するものは何もありません。

トークンは32バイトのランダムな値で、あるアドレスから別のアドレスを推測することはできません。
リンクは設定した日付に期限切れになります。
一度だけ使えます。注文が支払われた後、リンクは開けなくなるため、転送されたメッセージで2回支払われることはありません。

リスクルール

リスク画面には5つのルールがあり、それぞれ個別にオンにでき、それぞれ独自のしきい値を設定できます。これらはカードがいずれかのプロバイダーに送信される前に評価され、それぞれが注文にフラグを立てたり、審査待ちにしたり、直接拒否したりできます。

住所ごとの試行回数 — 1人の訪問者が一定期間内に行える支払い試行の回数です。
カードごとの試行回数 — 1枚のカードについての同様の回数です。
連続失敗 — 連続して発生した拒否の回数です。
国の不一致 — 請求先住所がトルコ国外にある、トルコ発行のカードです。
金額の上限 — まず確認したいと思う注文合計金額です。

住所もカード番号も記録されません。カウンターが保持しているのは自サイトのキーでソルト化されたダイジェストのみで、これによりルールは画面自体が2つ目のカードデータベースになることなく繰り返しを認識できます。デバイスフィンガープリントもなく、機械学習によるスコアもなく、BINのブロックリストもありません — 読める5つのルールがあるだけで、顧客に説明できないものは何もありません。

返金

5つの国際プロバイダーの場合、返金はWooCommerceの注文画面から通常どおりに——全額または一部——発行します。MevvPosは注文に記録された決済リファレンスに対して、プロバイダーに返金を送信します。

返金がライセンスによって制限されることは決してありません。顧客にお金を返せなくなることは、更新のリマインドが引き起こしてよいことではありませんし、ほとんどの国では法的義務でもあります。

トルコの銀行仮想POSは現時点ではWordPressから返金できません。MevvPosはこれを取り繕わずにそのまま伝えます。取引の返金は銀行自身の画面から行ってください。もし黙って成功と報告すれば、実際にはお金が銀行に残ったままWooCommerceは注文を返金済みとしてマークしてしまいます。誤った会計記録は、動かないボタンよりもはるかに高くつきます。

返金にはプロバイダーが返した決済リファレンスが必要です。そのリファレンスが記録される前に行われた注文、またはその後プロバイダーアカウントが削除された注文は、プラグイン経由では返金できません。

レポート

レポートタブには、売上、成功した取引、成功率、一括払いと分割払いの内訳が日次のグラフとともに表示されます。銀行からの応答をまだ待っている取引は別に数えられ、成功率には含まれません。

The revenue summary covers 7, 30 or 90 days in every installation. The Pro add-on adds three breakdowns on top of it:

分割払いと手数料の負担 — 分割回数ごとの件数、売上、手数料負担。
POS 別・銀行別の内訳 — POS ごと、発行銀行ごとの売上、成功、失敗、成功率。
拒否コードの分布 — CSV 書き出し付き。繰り返し現れる拒否コードは、直せる問題を指し示しています。残高不足はお客様側の問題ですが、3-D 認証や POS 設定のエラーはご自身の問題です。

レポートのもとになるデータを収集するのは無料版のプラグインです。そのため、Pro 版の有無にかかわらず履歴は蓄積され続けます。そうでなければなりません。アップグレードした時点で、過去のデータを後から作り出すことはできないからです。

導入したばかりのストアには、グラフがありません。記録はプラグインの導入とともに始まり、最初の決済の試行があってから画面が埋まっていきます。

WooCommerceなしでエンジンを使う

WooCommerceゲートウェイは、今では決済エンジンそのものではなく、その利用者の1つに過ぎません。エンジンは注文やカート、セッションについて何も知りません。渡すのは支払い意図（最小単位の整数の金額、通貨、リファレンス、戻りアドレス）で、それに対してエンジンはPOSTするフォームかリダイレクト先のアドレスのいずれかを返します。フォームプラグイン、予約プラグイン、あるいは独自コードも、チェックアウトと同じ方法でエンジンを動かすことができます。

MevvPos_Payment_Engine::start()は決済を開始し、ブラウザが次に何をすべきかを返します。
MevvPos_Payment_Engine::handle_webhook()は、決済の状態を変更する唯一の経路です。署名が検証できないイベントは何も変更せず、記録されるだけです。
MevvPos_Payment_Engine::webhook_url()は、プロバイダーのパネルに貼り付けるアドレスを構築します。
分割払いの上限は、最後の防衛線としてエンジン内でも適用されます——呼び出し元の画面は、ライセンスが切れる前に描画されていた可能性があるためです。

バージョン4.0.0より前にmevvpos_providersフィルターで独自プロバイダーを登録していた場合、今ではWC_Orderの代わりに支払い意図を受け取るようになります。7つのトルコファミリーのリクエストと署名は変わっていないため、既存のPOS設定は手を加えずに動作し続けます。

銀行申請とサポート

銀行リクエスト: まだ実装していない金融機関を、その理由とともに一覧表示します。プロトコル系統が判明していないか、系統は分かっているがドキュメントを待っている、のいずれかです。特定の金融機関について申請を出すことも、一覧に無い金融機関の名前を挙げることもできます。
サポート: 件名、対象となる POS または銀行、どの操作で何が起きるか、そして銀行が表示したエラーメッセージ。

サポートフォームでは、カード番号やセキュリティコードを含めないようお願いしています。決済の問題を切り分けるのに、それらが必要になることはありません。また、どちらのフォームでも決済情報やカード情報が送信されることはありません。

無料版のプラグインが当社サーバーに接続するのは、これらのボタンを押したときだけです。定期的に送信されるものはなく、無料版にライセンス確認の通信は一切ありません。

無料版と Pro 版

Nothing in the free plugin is locked, limited or counted. Every Turkish institution, every international provider, 3-D Secure, hosted-page checkout, wallets, multi-currency, currency and BIN routing, as many POS accounts as you have merchant agreements, instalments to twelve, test mode, refunds, pre-authorisation, payment links, the risk rules and the 7 / 30 / 90 day revenue report all work with no key and no account. Pro is a separate plugin whose code is not in the free package at all — it adds capabilities rather than raising a ceiling.

無料: Everything on this page unless it says otherwise: unlimited provider and POS accounts with BIN and currency routing, instalments to twelve, the 7 / 30 / 90 day revenue report, the packaged BIN table, pre-authorisation, payment links, risk rules, refunds and unlimited transaction volume. Apple Pay and Google Pay too, because they appear on the provider’s hosted page by themselves.
Pro: Recurring payments and subscription billing, the mandate store, stored payment authorisations in My Account, SCA exemption requests, the POS / bank / instalment / decline-code breakdowns with CSV export, and a weekly live BIN refresh. A separate plugin, downloaded from your account here — it is not on WordPress.org.

Multi-currency and routing by currency are both free. They were briefly sold with Pro; charging for the ability to point a euro order at the euro account was pricing a limitation rather than a capability, and it is gone.

ライセンスが失効した、または無い場合:

Nothing in the free plugin changes. It does not ask about licences at all — the question was removed from that package in 4.9.1 — so every account, every instalment plan, every route and the whole revenue report keep working exactly as before.
Your store keeps taking payments. There is no licence check anywhere on the payment path. Cutting off a shop’s revenue is not an acceptable way to send a renewal reminder.
返金は引き続き機能します。そもそも制限の対象になっていないためです。
Recurring charges already scheduled stop being taken, and the subscription screens go quiet. Mandates and stored authorisations are never deleted; they resume on renewal.
The breakdowns and CSV export stop. The 7 / 30 / 90 day report underneath them is in the free plugin and stays. Collected history is not deleted.
BIN の自動更新は止まりますが、同梱の表は動き続けます。

当社のサーバーに接続できない場合でも、有効なライセンスは最後に成功した確認を根拠に 7 日間は動作し続けます。ただし、ライセンス自体の有効期限を過ぎている場合は、いずれにせよ失効として扱われます。そうでなければ、当社のアドレスを遮断することが、ライセンスを 1 週間延ばす手段になってしまいます。

更新

Proプラグインには、ライセンスに紐づいた更新機構が組み込まれています。そうする必要があるのです。ProはWordPress.orgでは公開されていないため、WordPressが新しいバージョンの存在を知る手段がありません。ライセンスが有効であれば、Proの更新は他のプラグインと同様にプラグイン画面に表示されます。

無料版プラグインも、自分の更新を告知するようになりました。新しいバージョンがあるかを当社サーバーに尋ね、その答えを WordPress 自身の更新の流れに渡します。そのため新しいリリースは、誰かが手作業で zip を取りに行くのを待つのではなく、プラグイン画面にごく普通の更新ボタンとして現れます。リクエストが運ぶのはパッケージ名とインストール済みバージョンだけで、サイトのアドレスも、メールアドレスも、ライセンスキーも、プラグインの一覧もありません。あなたを特定するものが何も含まれないため、信頼はもっぱら署名にかかっています。応答は当社の Ed25519 鍵で署名されており、署名がない・署名が合わない・古いタイムスタンプから再生された・ダウンロード先が当社以外のホストを指す応答は、サイトに触れることなく破棄されます。POS の記録、認証情報、蓄積された履歴は WordPress のオプションと注文メタに保存され、更新がそれらに触れることはありません。

うまく動かないとき

銀行がすべての決済を拒否し、有益なメッセージも出ない: ほとんどの場合、署名が原因です。署名が誤っていても、どこにもエラーは出ません。銀行はただ拒否するだけです。加盟店番号、ストアキー、そしてその系統で必要な追加の認証情報を確認してください。いずれも署名に組み込まれます。有用な確認方法として、銀行は署名エラーと無効なカードとで異なる応答を返します。「無効なカード」というメッセージが返るなら、署名は正しいということです。
POS が複数あるとき、戻りで「ハッシュエラー」が出る: 戻りは、セッションを持たない別のリクエストです。MevvPos は、その注文がどの POS を使ったかを記録し、その鍵で検証します。決済に使われた POS レコードを削除してしまうと、検証は既定の POS にさかのぼって行われ、失敗することがあります。
顧客がStripeやPayPalで支払ったのに注文が保留のままになる: Webhookアドレスに到達できないか、登録されていません。注文を完了させるのは顧客の戻りではなく通知なので、Webhookが機能していない状態は、一度も支払っていない顧客とまったく同じに見えます。Bank APIタブに表示されているアドレスが、プロバイダーのパネルに保存されているものと一致していること、そしてプロバイダーのテストイベントが届くことを確認してください。
Squareのイベントがすべて拒否される: Squareは通知アドレスと本文をあわせて署名します。Squareに登録されたアドレスは、Bank APIタブのアドレスと一字一句一致していなければなりません——末尾のスラッシュ、httpsではなくhttp、あるいは一方にはあり他方にはないwwwだけでも十分に問題になります。
Authorize.Netのイベントがまったく検証されない: Signature keyはTransaction Keyとは別の値であり、2つを取り違えやすくなっています。Webhookの検証にはSignature keyのみが使用されます。
お客様が空の支払いページに着く、または Öde (支払う) ボタンが反応しない: キャッシュや最適化のプラグインがスクリプトを遅延させています。LiteSpeed では、mevvpos、jquery、および WooCommerce のフロントエンドスクリプトを遅延の対象から除外してください。カードフォームは既定で表示されるため処理自体は進みますが、自動転送は動きません。
決済に成功したのに、注文が「保留中」のまま: 銀行または決済事業者が、コールバックのアドレスに到達していません。?wc-api=mevvpos_callback が外部から到達できるか確認してください。メンテナンスモード、IP 制限、サイト前面のログイン要求は、これを遮ります。
決済フォームが同じページに送信されてしまう: アドレスが自動入力されない銀行で、Gate URL の欄が空になっています。銀行または決済事業者から渡されたアドレスを入力してください。
テストモードなのに、決済が本番の銀行へ送られる: テストモードは自動リダイレクトを止めてリクエストを表示しますが、NestPay系の銀行のゲートウェイアドレスを書き換えることはありません。テスト中は銀行のテストアドレスをGate URLに入力してください。StripeとMollieでも、この切り替えによってアドレスが変わることはありません——そこではサンドボックスを選ぶのはテストキー自体です。
分割払いが表示されない: Either the rate for that count is empty rather than zero, the card is from another bank, or the selected provider is an international one and has no instalments at all.
アップグレード後、カードが誤った POS に振り分けられる: 旧バージョンには手書きの BIN 範囲が含まれており、一部が誤っていました。各 POS が、実際に開設している銀行の下に登録されているか確認してください。
管理画面のスタイルが当たらない、または修正が反映されない: ブラウザのキャッシュが古くなっています。キャッシュを迂回してページを再読み込みしてください。

できないこと

以下はいずれも意図したものです。不具合ではありません。

トルコの銀行仮想POSでは返金できません。 どのトルコ系も返金呼び出しを持ちません。銀行自身の画面から返金してください。国際プロバイダーは対応しており、WooCommerce はそれらに返金ボタンを表示します。
The updater depends on where you got the plugin. The build downloaded from mevvsoft.com updates itself from our servers. The build published on WordPress.org does not carry that code at all — a plugin hosted there must be updated through WordPress.org, so the two packages differ in exactly this one file.
継続課金は国際プロバイダーでのみ動作し、保存カードの選択画面はありません。 保存された引き落とし許可は作成・更新・再試行され、延滞として記録されます。WooCommerce Subscriptions の商品がコードなしで設定します。不足しているもの：トルコの銀行仮想POS群はこれを扱えず、購入者は決済時に保存カードを選べず、催促スケジュールも管理画面からの解約もありません。
事前与信は存在しますが、すべての場所ではありません。 POSは金額を保留し、後で注文画面から全額または一部を確定するか、保留を解除できます。これに対応しているのはNestPay銀行グループ、Stripe、Authorize.Net、Checkout.comのみです。それ以外のすべてのプロバイダーは即時決済で、この設定自体が表示されません。
No rule-based routing. Routing is by currency and issuing bank only — not by amount, card brand or country.
Routing asks the currency first and the issuing bank second, in every installation. What is still missing is everything past that: no failover to a second account, no cascading retry, and no routing by amount, card brand or country.
どちらのチェックアウトもサポートされています。 クラシックな決済フォームとWooCommerceのチェックアウトブロックの両方が提供され、分割払い表とその手数料はどちらでも同じように動作します。ブロックは選択されたBINと分割払いをStore API経由で書き込むため、手数料はクラシックページと同じコードで計算されます。
3D Pay Hostingは意図的に採用していません。ホスト型ページはPCI適用範囲を減らしますが、同時にBINと分割払い表も失わせてしまいます——そしてトルコ側の価値のすべては、それらが可能にするルーティングにあります。国際プロバイダーがホスト型なのは、まさにそこにルーティングする対象が何もないからです。
BIN の編集画面はありません。この表は当社が管理し、自動更新によって統合されます。手作業で編集する画面は用意していません。
26 の金融機関が一覧に載っていますが、未実装です。不足がはっきり見えるように、表示したままにしてあります。
NestPay を除くすべての事業者は、自らベータと宣言しています。実際の加盟店アカウントで端から端まで検証できるまで、この表示は続きます。
タブはページ内のものです。サイドバーの項目は MevvPos の画面を開きます。タブの切り替えは、そのページ上で行ってください。

いかなる形でも保存されないもの：カード番号、有効期限、セキュリティコードです。トルコ側で保持されるカードデータは最初の6桁とそれが示す銀行のみです。国際プロバイダーではそれすらありません。カードがサイトに入力されることが一切ないためです。セキュリティコードの保存はどんな状況でも禁止されており、マスクしたものであっても桁数が漏れてしまいます。

単一のエンジン：トルコの銀行仮想POSと国際プロバイダー。