EPC QRコード：SEPA決済QR規格を解説

EPC QRコードにはリンクが含まれていません。含まれているのはSEPA振込であり、短いプレーンテキストのブロックとして書き出されたものです。このフォーマットを認識する銀行アプリがそれを読み取り、振込フォームに入力します。どのサーバーにも接続されず、何も照会されず、スキャンに関する情報はあなたのもとには一切届きません。

この一つの事実が、これらのコードの使われ方すべてを決めています。短縮することもできず、向き先を変えることもできず、スキャン数をカウントすることもできません。この流れのどこにもリクエストが存在しないからです。背後にある規格はEuropean Payments CouncilによるEPC069-12であり、ドイツ語圏の市場ではこれらのコードは通常GiroCodeと呼ばれています。請求書に何千枚も印刷する前に、このフォーマットを正確に理解しておく価値があります。QRコードが一般に何を運べるかについては、QRコードとは何かがペイロードの問題を扱っています。

ペイロードに実際に含まれているもの

ペイロードは固定順の行の並びで、それぞれの行が個別の要素になっています。パーサーは1行目を読み取ってBCDであることを期待し、4行目を読み取ってSCTであることを期待し、どちらか一方でも欠けていれば処理を諦めます。

つまずきやすいルールが2つあります。構造化参照番号と自由記述テキストは互いに排他的で、一方を入力したらもう一方は空欄のままにします。そして金額は省略可能であり、支払う側が金額を決める寄付用コードでは正しい選択ですが、正確な金額を事前入力したい請求書では誤った選択になります。

ブロック全体は331バイトに制限されています。EPC069-12 guidelinesは誤り訂正レベルをMに固定し、シンボルをバージョン13に制限してもいるため、印刷するコードのモジュール数には既知の上限があります。ジェネレーターをクリックするのではなくコードでこれを構築するなら、Segnoライブラリのドキュメントにフィールドの順序と符号化ルールが、テストできる形でまとめられています。

短縮も追跡もできない理由

追跡可能なQRコードは、自分が所有するURLを符号化することで機能します。スキャンするとそのURLが開き、あなたのリダイレクトが応答し、リクエストがカウントされ、訪問者は現在リンクが指している場所に到達します。ダイナミックQRコード対スタティックQRコードがこの仕組みを詳しく解説しています。

ここではそのどれも当てはまりません。銀行アプリはブラウザではありません。テキストを解析し、フォーマットに一致させ、端末上でローカルに決済フォームを開くだけです。傍受すべきHTTPリクエストが存在しないため、次のようになります。

• スキャン数はどこにも存在しません。あなたのツールにも、銀行のツールにも。
• 向き先を変えることはできません。IBANを間違えたら再印刷するしかありません。
• ペイロードを短縮リンクで包むと完全に壊れます。パーサーはBCDを期待している場所にhttpsを見ることになるからです。

誰かが仕様書を読むまで、決済コードにアトリビューションを持たせようと1週間を費やしたチームを見たことがあります。正直な答えは、決済側と計測側はそれぞれ別のコードであり、レイアウトに1つ分の余裕しかないなら決済コードが優先されるべきだということです。

計測できるのは、その周りにあるすべてです。郵送物に決済コード付きの請求書が入っているなら、顧客ポータルや利用規約、サポートページへの別の追跡可能な短縮リンクを同じ手紙に載せ、そちらのエンゲージメントを読み取ってください。ElidoのQRコード機能がシートの追跡可能な半分をカバーし、決済コードは規格が求めるとおりのままにしておけます。

どこで機能し、どこで機能しないか

対応の可否は個々の銀行アプリの側にあり、それが国別リストが過大評価しがちな不均一さを生んでいます。オーストリアとドイツのアプリはこのコードを何年も読み取ってきており、フィンランドとオランダのアプリも概ね信頼できて、ベルギーの対応も良好です。それ以外の国では、大量印刷に踏み切る前にテストしてください。

よく混同される近縁のものが2つあります。スイスのQR-billは独自のレイアウトを持つ別の規格で、シンボルの中央にスイスの十字が入っており、EPCコードではないためユーロ圏のアプリは決済として読み取りません。そしてカード決済処理業者の決済リンクはこれとはまったく別物です。それはQRの中に入った普通のURLであり、先にホスト型のチェックアウトページがあるだけで、それに付随する追跡も含めて他のあらゆるWebリンクと同じように振る舞います。

規制対象の決済業者や貸付業者が顧客に何を提示できるかという、より広い問いについては、フィンテック向けURL短縮サービスがリンクが関わる部分を扱っています。

後悔しないために作る

お金を節約できる順に並べた6つのチェック項目です。

1. IBANは生成前に検証し、印刷後には検証しないこと。チェックサム検証は無料ですが、再印刷には1回分の費用がかかります。
2. 金額を入れるかどうかは意図的に決めること。請求書なら固定、どんな金額でも受け付けたい寄付用ポスターなら空欄にします。
3. 自由記述テキストより構造化参照番号を優先すること。より短く、会計上の自動消込ができ、ペイロードも小さく保てます。
4. 少なくとも3つの銀行アプリで、両方のスマートフォンプラットフォームでテストすること。パーサーによって、省略可能なフィールドをどれだけ厳密に扱うかが異なります。
5. 他のどのコードとも同様に、スキャンされる距離に合わせて印刷サイズを決めること。QRコードはどれくらいの大きさにすべきかに計算方法がまとめてあります。
6. マット仕上げにすること。オフィスの照明の下で、請求書上の決済コードに光沢のあるニス仕上げをすると、サポートチケットが発生するのを待つだけになります。

ステッカー問題

実在する不正の経路が1つあり、それはデジタルではなく物理的なものです。請求書やパーキングメーター、市場の屋台の看板、チャリティーポスターに印刷されたスタティックな決済コードは、別のIBANを記載したステッカーで覆われてしまうことがあります。コードの中には、それに抵抗する仕組みは何もありません。ペイロードとは紙そのものだからです。

対策も同じく物理的なものになります。コードは粘着シールの上ではなく、貼り付けたラベルであれば一目で分かるような請求書のレイアウトの中に印刷してください。受取人名とIBANの末尾の数桁をコードの横にテキストで表示し、支払う側が照合できるようにしてください。そして決済確認の案内では、確認する前に銀行アプリに表示される名前を読むよう伝えてください。すり替えが見えるのはその画面だけだからです。QRコードは安全か、クイッシングとは実際何かがより広い攻撃パターンを解説しており、その大半は同じページの別の場所に印刷するリンクコードにも当てはまります。

安心できる点として、決済には依然として認証済みの銀行アプリで人が確認する工程が必要です。コードはフォームに入力するだけで、お金を動かすことは決してありません。

コーナーストーンシリーズを読む

この記事は機能クラスターに属しています。生成するあらゆるコードをめぐる印刷ワークフローについては、QRコードキャンペーンをゼロから作るがコーナーストーンであり、ドキュメントのQRコードガイドがAPI経由で追跡可能な種類を生成する方法を解説しています。

ブログの関連記事

• ダイナミックQRコード対スタティックQRコード：どちらが正しい場面か
• QRコードとは何か、何を運べるのか
• QRコードとGDPR：スキャンで何が収集されるのか
• フィンテックチーム向けURL短縮サービス
• QRコードはどれくらいの大きさにすべきか