カスタムPOSアプリでクレジットカード決済を受け付ける方法

カスタムPOSアプリでクレジットカード決済を受け付けるには、決済サービスプロバイダー（PSP）と連携し、認定カードリーダー、Tap to Pay on iPhone、Tap to Pay on Android、またはクラウド接続型スマートターミナルの4つのルートのいずれかを選択します。アプリがカード番号を直接読み取ることはありません。アプリは認定ハードウェアまたはソフトウェアに金額を送信し、承認または拒否の結果を受け取ります。ルートごとにApple、Google、またはプロバイダーからの要求事項が存在し、時間を要するのはコード作成ではなく、これらの手続きや書類作業です。

本ガイドでは、過剰な表現を排し、実際の要件に基づいた全ルートをステップバイステップで解説します。私たちは自社のPOSであるFinalで決済機能を運用しているため、これらのすべてのプロセスを経験しています。

なぜPOSに単なるカード入力フォームを追加してはいけないのか？

入力フォームでの決済は「非対面決済（Card-Not-Present）」扱いとなり、実店舗のレジで求められるのは「対面決済（Card-Present）」だからです。顧客がウェブフォームにカード番号を入力する場合、オンライン注文と同様に扱われ、高額な手数料、高い不正利用リスク、チャージバックリスクを加盟店側が負うことになります。認定デバイスがカードやスマートフォンを直接読み取る場合、対面決済として処理され、手数料を抑えられ安全性も高まります。

対面決済の導入には、認定されたハードウェアまたはソフトウェアが必要です。そのため、以下で紹介するすべてのルートは自作コードではなく、PSPの対面決済向けプロダクトを使用します。手数料の違いについては対面決済 vs 非対面決済で説明しています。

ルート1：自作アプリでカードリーダーを使用する方法

対面決済用SDKを提供するPSPを選択し、その認定リーダーを購入してアプリからペアリングします。Stripe TerminalやAdyenなどがこの方式です。

1. PSPでアカウントを開設し、対面決済プロダクトを有効化します。

2. iOS、Android、またはReact Native向けSDKを組み込みます。

3. 認定リーダーを注文し、自社アカウントに登録します。

4. アプリからリーダーを検出・接続し、SDK経由で決済を処理します。

5. PSPから配信されるリーダーのファームウェアアップデートの運用を計画します。

任意のリーダーを接続することはできません。認定はリーダー、ソフトウェア、プロセッサーの組み合わせに対して行われるため、契約プロバイダーが認定したリーダーのみが決済処理を行えます。詳細はカスタムPOSアプリ向けカードリーダーおよびPOS向けEMV認定をご覧ください。

ルート2：Tap to Pay on iPhoneに必要な要件は？

Tap to Pay on iPhoneは、スマートフォン自体を決済端末にする機能です。Apple公式のステップは、対応PSPとの連携、Tap to Pay on iPhoneエンタイトルメントの申請、ProximityReader APIまたはPSPのSDKの組み込み、AppleのHuman Interface Guidelinesの遵守、アプリのレビュー提出です（AppleのTap to Pay概要）。Appleは、加盟店が決済を受け付けるための認証はPSPが責任を持つと明記しています。

実際には以下の準備が必要です：

1. 組織デベロッパーアカウント： エンタイトルメント申請は組織アカウントのアカウントホルダーが行う必要があり、組織登録にはD-U-N-Sナンバーが必要です。D-U-N-SナンバーとAppleデベロッパーアカウントを参照してください。

2. 申請フォームの提出： 利用するPSPと運用地域を指定します。

3. 開発用エンタイトルメント： 自社デバイスでの構築およびテスト用にAppleから発行されます。

4. AppleのUX要件への準拠： エンタイトルメントと共にボタン表記、エントリーポイント、オンボーディングに関するガイドラインが届きます。

5. 配布用エンタイトルメント： Appleからのメールに返信して配布用を再申請します。TestFlightやApp Storeでの配信に不可欠です。

6. App Review（アプリ審査）： 審査を通過すれば配信可能になります。

iPhone XS以降で動作し、iPadでは動作しません。完全な解説はTap to Pay on iPhoneエンタイトルメントの取得方法を、審査対策はTap to PayアプリのApp Review通過ノウハウを、代替案はなぜiPadでTap to Payが動かないのかをご覧ください。

ルート3：AndroidのTap to Payの違いは？

AndroidにはAppleのようなエンタイトルメント制度はありませんが、PSPのSDKが独自の検証を行います。一般的な条件：

• Android 11以降を搭載し、NFCを内蔵したAndroidデバイス

• セキュリティ整合性検証（Attestation）を通過したGoogle認定デバイス

• 非デバッグビルド（PSPのSDKはデバッグモードでの本番決済を拒否するため、テスト時はモックリーダーを使用）

• 位置情報など、SDKが要求する権限の許可

Androidタブレットは、プロバイダーの要件を満たしていれば使用可能です。詳細はカスタムアプリにおけるAndroidのTap to Payを参照してください。

ルート4：ウェブベースのPOSでカード決済を受け付けられるか？

クラウド接続型のスマートターミナルを使用すれば可能です。サーバーからPSPのAPIに命令を送り、レジにある特定端末へ決済リクエストを送信します。端末側でカード読み取りを行い、結果がサーバーに返されます。ウェブページ単体ではタッチ決済を読み取れず、SafariからBluetoothリーダーへアクセスすることもできないため、これがウェブPOSで利用可能な唯一の対面決済ルートとなります。

固定端末を設置するカウンターサービス店舗に適しています。ネットワーク依存が発生するため、店舗の通信が切断された場合の運用手順を準備しておく必要があります。

カスタムPOS向け決済プロバイダーの選び方

まず販売展開する国を確認し、次にオンボーディング手続きとハードウェアを評価します。

比較詳細はStripe Terminal vs Adyen：カスタムPOSアプリでの比較をご覧ください。他事業者の決済を代行する場合は、まず決済ファシリテーター（ペイファック）になるかプラットフォームを利用するかをお読みください。単一店舗の運用であれば通常の加盟店契約となります。

どのようなコンプライアンスが適用されるか？

PSPの認定SDKやリーダーを使用する場合、カードデータが自社コードを通過しないため、PCI DSSの適用範囲は最小限に抑えられます。決済のセキュリティ認定はPSPが担保します。ただし加盟店側で以下を管理・維持する必要があります：

• 決済プロセッサーとのPCI自己問診シート（SAQ）の記入

• POSを実行するデバイスのアクセス制御、ログ記録、アップデート管理

• 正確なレシート発行、返金、税金の逆算処理

• Tap to Payに関するAppleおよびPSPの表示・マーケティングガイドラインの遵守

POSの他のコンポーネントも自作する場合は、AIで独自POSシステムを構築する方法でPCI、税金、デプロイについて、カスタムアプリ向けPOSハードウェアでプリンターやドロワーについて解説しています。

初回のカード決済受領までにどれくらいの期間がかかるか？

初日からカード決済を受け付ける方法は存在するか？

すでに各種承認を保有しているプラットフォーム上でチェックアウトを構築すれば可能です。それがFinalです。AIがFlow Studioでチェックアウトを構築し、カード決済のリクエストが発生すると、Final PayがリーダーまたはTap to Payの処理を担当します：

• リーダーおよびTap to Payは承認済み： Final Payは対応デバイスでのカード、コンタクトレス、Tap to Pay決済に対応しています。Tap to Pay決済の受け付け方および会計時の決済受領方法をご覧ください。

• 独自のAIで構築： FinalのMCPサーバー経由でClaude、Cursor、その他のMCPクライアントを接続します。

• 明確でシンプルな料金体系： サブスクリプション料金はありません。現金決済は$0。カード決済は米国および世界各地で2.49% + $0.10、カナダで1.99%、欧州で0.99%です。

正直なトレードオフ：独自のプロバイダーを選択するのではなくFinal Pay経由で処理することになり、利用可能性は国やデバイスによって異なります（Final Pay利用可能地域に記載）。決済機能自体をプロダクトとして開発する場合は、上記のルートで自社組み込みを行ってください。売上を回収する手段として決済が必要な場合、承認手続きはすでに完了しています。