LASSIC Media らしくメディア
アプリにApple Pay/Google Pay決済を実装する外注の進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Apple Pay/Google Payは物理商品・実サービス向けの決済ネットワーク連携であり、デジタルコンテンツのアプリ内課金（IAP）とは用途・審査要件が異なります。
- 実務ではStripeやPAY.JP等の決済代行（PSP）を介した実装が主流で、PCI DSS対応の複雑さを大幅に軽減できます。
- 外注先の選定では、PassKit/Google Pay API実績・PSP連携経験・Apple審査対応の3点を重点確認することで、審査リジェクトや手戻りリスクを抑えられます。
目次
Apple Pay/Google Payとは ── IAPとの違いを理解する
Apple Pay/Google Pay（Google Pay API for Android）とは、スマートフォンアプリ内でクレジットカードやデビットカードの決済を端末のセキュリティ認証（Face ID・Touch ID・生体認証）を用いてトークン化処理する、決済ネットワーク連携の仕組みです。
Apple PayはiOS/iPadOS/watchOSアプリおよびSafari上で動作し、PassKit（パスキット）フレームワークを通じてMerchant ID（マーチャントID）と決済処理業者を介して代金を受け取ります。Google Pay API for AndroidはAndroidアプリ内での高速チェックアウトを実現し、Google アカウントに保存された数億枚のカードへアクセスできます*1*2。
Apple Pay/Google Payが対象とする取引
Apple Pay/Google Payが適用できるのは、物理商品の購入・飲食店の支払い・タクシーや各種サービスの利用など、現実世界の取引です。アプリが仲介する実商品・実サービスへの決済に広く使えます。
一方で、「アプリ内でゲームの追加コンテンツを購入する」「サブスクリプションを契約する」といったデジタルコンテンツ・機能の取引には、AppleのIn-App Purchase（IAP・StoreKit）またはGoogle Play In-App Billing（Play Billing）の利用がプラットフォームポリシー上の原則です。
アプリ内課金（IAP）との線引き ── 審査リジェクトを防ぐ判断基準
この線引きを誤ると、App Store/Google Playの審査でリジェクトされるリスクがあります。
Appleのガイドラインでは、アプリ内で消費・利用されるデジタル商品・コンテンツはIAPを使わなければなりません。Apple Payを使えるのは物理商品・実サービスの決済に限られます。Google Playも同様に、デジタルコンテンツにはGoogle Play In-app Billingの使用を求めています*3。
外注を始める前に「今回の決済は物理商品かデジタルコンテンツか」を整理し、IAP（id992の記事で解説）とApple Pay/Google Payのどちらが適切かを確認しましょう。
Apple Pay実装の技術要件と外注前に把握すべき工程
PassKit/PKPaymentRequestの概要（iOS）
iOSアプリにApple Payを組み込む際の中心的なフレームワークはPassKit（PassKitフレームワーク）です。PassKitはAppleの公式ドキュメントに記載された標準APIで、決済シートの表示・認証・完了処理を一元管理します*1。
実装の主要コンポーネントは次のとおりです。
- PKPaymentRequest：決済リクエストオブジェクト。金額・通貨・商品情報・Merchant IDを設定します。
- PKPaymentAuthorizationViewController：決済シートを表示するUI。Face ID / Touch IDによる生体認証もここで処理されます。
- PKPaymentToken：認証後に発行されるトークン化された決済データ。実際のカード番号を含まないため、マーチャント側での機密情報保持が不要です。
外注先がPassKitの実装経験を持つかどうかは、開発品質に直結します。Xcodeの「Signing & Capabilities」でApple Pay Capabilityを追加する設定から、PKPaymentRequestの生成・PKPaymentAuthorizationViewControllerの表示・コールバック処理まで、一連のフローに習熟した開発者が必要です。
Merchant ID取得〜証明書設定〜サーバー側処理の流れ
Apple Pay実装には開発コード以外にも、Apple Developer Portal側の設定作業が必要です。手順は大きく以下の流れになります。
- Apple Developer Portalにアクセスし、Merchant IDを作成する
- Merchant ID用のApple Pay Payment Processing Certificateを生成・登録する
- Xcodeの「Signing & Capabilities」でApple Pay Capabilityを追加し、Merchant IDを紐づける
- クライアント（アプリ側）で生成されたPKPaymentTokenをサーバーに送信する
- サーバー側で決済代行（PSP）に対してトークンを渡し、実際の決済処理を行う
このDeveloper Portal操作・証明書管理はフロントエンド開発とは異なる知識領域です。外注の際はこの工程を含む範囲でスコープを定義し、証明書の有効期限管理まで契約範囲に含めておくことを検討してください。
Google Pay実装の技術要件と外注前に把握すべき工程
Google Pay API for Androidの概要
Google Pay API for AndroidはAndroidアプリへの高速チェックアウト機能を提供します。Googleアカウントに保存されたカード情報を活用し、世界中の数億枚のカードへアクセスできます*2。
主要な技術要素は次のとおりです。
- PaymentsClient：Google Payの決済機能を呼び出すクライアントオブジェクト
- IsReadyToPayRequest：デバイスがGoogle Pay利用可能かを確認するAPIリクエスト
- PaymentDataRequest：決済金額・通貨・支払いオプションを指定するリクエストオブジェクト
- PaymentData：決済完了後に返却されるトークン化された決済データ
Gradle build fileには `com.google.android.gms:play-services-wallet` の依存関係追加が必要です。`minSdkVersion` は23以上、`compileSdkVersion` は34以上が要件となります*2。
依存関係・PaymentsClient・本番申請の流れ
Google Payの実装では、開発環境での動作確認後に本番アクセス申請が必要です。流れは次のとおりです。
- Terms of ServiceとAcceptable Use Policyを確認・同意する
- 対応する決済処理業者（PSP）のリストから自社の業者を選定・契約する
- Googleのブランドガイドラインに準拠したGoogle Payボタンを実装する
- テスト環境でGoogle提供のテストカードを用いて動作検証する
- Google Pay & Wallet Consoleで本番アクセスを申請・承認を受ける
本番申請は統合チェックリストを完了した後に行います。外注先が申請プロセスの代行経験を持っているかどうかは確認が必要です。申請不備や審査待ちによるリリース遅延は、プロジェクト全体の工程に影響します。
決済代行（PSP）経由実装が主流の理由
PCI DSS対応・トークン処理の実務
Apple Pay/Google Payを自前のサーバーで直接処理しようとすると、クレジットカード業界の国際的なセキュリティ基準であるPCI DSS（Payment Card Industry Data Security Standard）への準拠が求められます。
PCI DSS準拠は、定期的な脆弱性スキャン・ペネトレーションテスト・ログ管理・アクセス制御など広範な対応を伴い、専門知識と継続的な運用コストが発生します。
これを避けるために実務では、StripeやPAY.JPなどのPSP（Payment Service Provider、決済代行サービス）を介した実装が主流です。PSP側がPCI DSS準拠の環境でカード情報・トークンを処理するため、アプリ開発側はPCI DSS対応の複雑さを大幅に軽減できます。
主要PSPの比較ポイント
PSPの選定はApple Pay/Google Pay実装の成否に直結します。選定の主な観点は次のとおりです。
| 確認項目 | 内容 |
|---|---|
| Apple Pay/Google Pay公式対応 | PSPがApple/Google双方の公式Approved PSPリストに掲載されているかを確認します。 非公式のPSPでは本番申請が通らない場合があります。 |
| 日本円・国内銀行対応 | 国内向けサービスでは円建て決済・国内主要銀行のカード対応が必要です。 海外PSPは対応状況を事前確認してください。 |
| SDK・ドキュメントの充実度 | iOS/Android向けSDKの品質・サンプルコードの充実度は外注開発の工数に直接影響します。 外注先の使用実績があるPSPを選ぶと連携がスムーズです。 |
| 手数料体系 | 初期費用・月額固定費・トランザクション手数料の組み合わせはPSPにより異なります。 費用の詳細は各PSPの公式サイトで最新情報を確認してください（本記事では掲載しません）。 |
| サポート体制 | 審査申請時や本番障害時の日本語サポートの有無は運用面で重要な差異となります。 |
外注先がどのPSPの実装実績を持つかをRFP（要求仕様書）に明記し、見積もり時点で確認しておくことを推奨します。
外注先の選び方 ── 実績で見るべき5つのポイント
技術要件（PassKit/Google Pay API・PSP連携実績）
Apple Pay/Google Pay対応の外注先を選ぶ際、技術観点で確認すべき5点を整理します。
- PassKit/Google Pay APIの実装実績：デモ環境の提示を求め、PKPaymentAuthorizationViewControllerの実装例・Google Pay ボタンの表示実装を確認します。
- PSP連携経験：Stripe/PAY.JP等の具体的なPSPとのAPI連携実績を確認します。トークン処理・Webhook実装まで含めて対応できるかを確かめましょう。
- Apple Developer Portal操作経験：Merchant ID作成・証明書発行・Capability設定など、Appleの開発者アカウント管理に慣れているかを確認します。
- App Store/Google Play審査対応：決済機能を含む審査通過経験と、リジェクト時の対処ノウハウを持つかを確認します。Apple PayはApp Reviewガイドラインへの準拠が必要で、審査リジェクトは珍しくありません。
- セキュリティ要件の理解：PCI DSS・トークン化・暗号化通信（TLS 1.2以上）の実装知識を確認します。決済機能は脆弱性が直接的な金銭被害につながるため、セキュリティの実装品質は特に重要です。
審査対応・セキュリティ要件の確認ポイント
決済機能の実装ミスやセキュリティ対策の不備は、アプリストアからの削除要求やユーザーへの金銭的被害に直結します。外注先の選定時には過去のセキュリティ事故対応経験を確認することが大切です。
また、外注先にApple Pay機能の実装を依頼する場合、Apple Developer Programの費用（年額$99）はマーチャント（発注側）が負担する必要があります。外注費用の見積もりと別に計上してください。
外注先が見つからない場合やリソースが不足する場合は、決済専門のSI企業やフィンテック特化の開発会社に相談することも選択肢です。
外注費用レンジと工数目安（市場参考値）
規模別の費用目安
Apple Pay/Google Pay実装の外注費用は、既存アプリへの追加か新規開発かで大きく異なります。以下は市場での参考値であり、一次資料ではありません。実際の費用は外注先・スコープ・既存コードの状態によって変動します。
| 規模・条件 | 工数目安（市場参考値） | 留意点 |
|---|---|---|
| 既存アプリへの追加（iOS or Android片方） | エンジニア1〜2名 × 2〜4週間程度 | PSP連携済みなら短縮可。 Merchant ID申請・PSP契約は別途。 |
| iOS/Android両対応（クロスプラットフォーム） | エンジニア2〜3名 × 4〜8週間程度 | React Native/Flutter利用時は一部共通化可。 ネイティブ実装は各OS別対応が必要。 |
| 新規アプリへの組み込み（決済機能込み） | プロジェクト全体仕様による | 設計・バックエンド含む場合は 別途見積もりが必要。 |
内製対比の難易度と外注の妥当性
Apple Pay/Google Payを内製するには、PassKit/Google Pay APIの理解に加え、Apple Developer Portal操作・PSP連携・セキュリティ実装・審査対応と複数の専門領域が必要です。
iOS/Androidの決済実装に不慣れな内製チームが初めて対応する場合、審査リジェクトによる手戻りや、PSP連携の不具合解消に想定外の時間がかかるリスクがあります。
決済機能は障害発生時に売上損失に直結する重要機能です。実装経験のある外注先を活用してリスクを抑え、社内リソースをアプリの差別化機能の開発に集中させる判断は合理的です。
2025年スマホ競争法とApple Pay/Google Payの関係
2025年12月に施行された「スマートフォンにおけるソフトウェアの競争の促進に関する法律（スマホソフトウェア競争促進法）」は、モバイル決済の外部決済導線に関する規制環境に変化をもたらしつつあります。
この法律はApple/Googleのプラットフォーム支配力の規制を目的としており、アプリ内での外部決済手段への誘導に関するルールが変わる可能性があります。ただし、法律の解釈や実際の運用・施行状況は今後の行政指導・ガイドラインによって変動します。
外注でApple Pay/Google Pay決済を実装する際は、公開時点でのApp Store審査ガイドライン・Google Play ポリシーの最新内容を確認してください。法的な取り扱いについては、最新の公式ガイドラインおよび必要に応じて専門家（弁護士・認定資格者）への確認を推奨します。
まとめ ── Apple Pay/Google Pay外注の3つの判断軸
本稿では、アプリへのApple Pay/Google Pay決済実装を外注で進める際の要点を整理しました。判断軸を3つにまとめます。
第一に、IAPとの使い分けを最初に確定することです。デジタルコンテンツにApple Payを使おうとすると審査リジェクトになります。取引の性質を確認し、IAP対象かApple Pay/Google Pay対象かを要件定義段階で整理することが出発点です。
第二に、PSP選定を外注先と一緒に行うことです。PSPの選択はApple Pay/Google Payの実装品質・申請の通過率・運用コストに直接影響します。外注先がどのPSPの実装実績を持つかをRFPで確認し、対応PSPをプロジェクト開始前に確定してください。
第三に、審査・申請工程をスコープに明示することです。Merchant ID取得・Apple Pay Capability設定・Google Pay本番申請は開発コードとは別の作業です。外注契約の範囲にこれらを含めるか否かを明記し、リリース遅延リスクを事前に抑えてください。
よくある質問
Apple PayとGoogle Pay、両対応を外注する費用はどれくらいですか？
両プラットフォーム対応の場合、市場参考値ではエンジニア2〜3名規模で4〜8週間程度の工数が必要です。費用は外注先のスキルセット・既存コードの状態・PSP選定状況によって変動します。これはあくまで市場参考値であり一次資料ではないため、実際の見積もりは複数社から取得してください。
デジタルコンテンツの販売にApple Payは使えますか？
Appleのガイドラインでは、アプリ内で消費・利用されるデジタルコンテンツや機能の購入にはIn-App Purchase（IAP・StoreKit）の使用が原則です。Apple Payは物理商品・実サービスの決済に適用できますが、デジタルコンテンツへの適用はApp Reviewガイドライン違反になるリスクがあります。取引の種類に応じてIAPとApple Payを使い分けることが大切です。
Stripe等の決済代行を使う場合、外注先に何を求めればいいですか？
外注先にはStripe（またはPAY.JP等）のSDKを使ったトークン処理・Webhook実装・エラーハンドリングの実績を求めてください。PSP公式の実装ガイドへの準拠・テスト環境での動作確認・本番切り替え手順の明文化もスコープに含めることを推奨します。PSP連携実績を具体的に確認することで、予期しない不具合を減らせます。
Apple Pay/Google Pay実装の審査・申請にはどれくらい期間がかかりますか？
Apple Pay Merchant IDの取得・証明書設定は数日から1週間程度が目安ですが、書類不備があると追加対応が必要です。Google Pay本番申請は統合チェックリスト完了後に申請し、承認まで数営業日〜1〜2週間程度かかることがあります。いずれもApple/Googleの審査状況により変動するため、リリーススケジュールには審査期間のバッファを設けてください。
既存のECアプリにApple Pay/Google Payを追加するのは難しいですか？
既存の決済フロー（カート・注文処理・サーバーサイド）との整合性を保ちながら組み込む必要があるため、新規アプリへの実装より考慮点が増えます。特にサーバー側のトークン処理・既存PSPとの共存・UIの整合性が追加の検討事項になります。既存コードの構造によって工数が変わるため、外注前にコードレビューを含む調査フェーズを設けることを推奨します。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Apple Inc.「Apple Pay – Apple Developer」（参照2026年6月）
- *2 出典：Google LLC「Google Pay API for Android – Google for Developers」（参照2026年6月）
- *3 出典：Apple Inc.「App Store Review Guidelines – Apple Developer」（参照2026年6月）
