TWINTスイス：QRとアプリ内

1） TWINTの文脈および位置

TWINTは、スイスの銀行と統合されたスイスのモバイルA2A決済スキームとウォレットです。ユーザーはTWINT/銀行アプリケーションから支払います。オンライン-in-app/App2AppまたはDeep Link、オフライン-QR（標準「TWINT QR」）。確認はアプリケーション（SCA： PIN/バイオメトリクス）で行われ、資金は関連するアカウント/カードから引き落とされ、銀行のクレジットによって加盟店に入金されます。

• オンラインおよびPOSの高いユーザーの範囲のための統一されたブランド/QR。
• UXと迅速な決済（銀行窓口内）の即時オンライン確認。
• 生態系内の電話番号/連絡先によるP2P。
• SCAとデバイスバインディングによる不正行為が少ない。

2）メンバーと役割

TWINT（スキーマ/スイッチ）：ルール、参加者ディレクトリ、ルーティング。
TWINTのメンバー/発行者の銀行：KYC、限界および反詐欺。
PSP/acquirers：マーチャント（オンライン/POS）を接続し、API/SDK、 Webフック、レポートを提供します。
マーチャント：支払い/リクエストを開始し、ステータス/リターンを処理し、和解を維持します。
Payer： TWINT/bankアプリケーションで取引を確認します。

3）チャネルとユーザーシナリオ

3.1 Eコマース：アプリ内/ディープリンク/App2App

チェックで、商人は支払意思→Deep Link/「 Pay TWINT」ボタンを与える。
TWINTアプリケーションが開きます（App2App）、ユーザーが確認→ステータスでレジに戻ります。
デスクトップには注文ごとに動的なQRが表示されます。クライアントはアプリケーションをスキャンして確認します。

3.2 POS/オフライン： TWINT QR

キャッシュレジスタ/端末画面の動的QR：金額、orderId、メタデータ。
ユーザースキャン→アプリケーションで確認→商人がオンラインステータスを受け取ります。
静的QR（金額は手動で入力されます）は寄付/小売業に適用されますが、和解にはより悪いです。

3.3 P2P「電話ごと」

プッシュ確認と受信者へのインスタントクレジットと電話番号/連絡先で個人間の転送。

3.4リクエスト・ツー・ペイ・バイ・リンク

商人は支払いの要求を開始します（金額/予定/期限）→クライアントはアプリケーションで確認します→支払いは通常のA2Aフローを通過します。

4）状態およびタイミング

典型的なステータスは'initiated'→'pending'→'success'/'failed'/'cancelled'/'expired'です。
QR/デスクトップの場合は、確認のタイムアウトを考慮してください（タイマーを表示）。
決済：決済ウィンドウ/PSPに応じて銀行クレジットT+0/T+1。報告には日々の偵察が必要です。

5）制限とリスクポリシー

• トランザクションごと、1日あたり/24時間、時には毎週/毎月。
• 新しい受信機/商人-しきい値および/またはシャッター速度を減らしました。
• チャネルの限界：電子商取引（Deep Link/QR）、 POS、 P2P、 Request-to-Pay。
• 速度/デバイス/ジオルールは、銀行とスキームによって適用されます。

6）経済と手数料

商人のために、TWINTは通常典型的なカードMDRより安いです；PSPによって条件が異なります（修正/低い％）。
統合/SDK、保留/期限切れの処理、サポート/ODR、和解のための料金。

7）返品および紛争

チャージバック（カードと同様）がありません。返品-商人から支払者への新しいクレジット取引。部分的な払い戻しがサポートされています。
返却日は銀行（通常はT+0/T+1）です。
紛争/苦情-PSP/銀行手続きによると；注文ログ、サービス/配送の確認、refund↔orderの束を保管してください。

8）安全性とコンプライアンス

TWINT/bankアプリケーション（PIN/バイオメトリクス）のSCA、デバイス結合。
銀行/PSPでの不正行為：速度、新しい受信者、リスクスコアリング。
PII最小化と暗号化、Webフック上のHMAC/nonce、リプレイ保護、監査ログ。
現地の決済サービス要件とGDPRに匹敵するデータ保護規制を満たしています。

9）マーチャントの統合

［オプション］

1.PSPでホスト/エンベデッド-高速起動、アプリ内/QR、ステータス、エラー。
2.Server-to-Server+Deep Link/QR-ネイティブUX、注文ごとの動的QR、細かいエラー処理。
3.Pay-by-Link/Request-to-Pay-リンク（電子メール/SMS/メッセンジャー）での請求。

• API： 'createPayment'、 'refund'、 'requestToPay'、 'webhook'、 'reconcile'。
• Idempotence （'orderId'+key）、指数関数リトレイ、イベントのデッドアップ。
• Recon：毎日のオートリコン+定期的なフルリコン；UTR/bankリファレンスを保存します。
• SLAダッシュボード：変換、'保留中→成功/期限切れ'、登録/返却までの時間。

10）和解と報告

ログ：プロバイダの'paymentId/transactionId'、 'orderId'、チャネル（App2App/QR/Link）、支払者銀行、ステータス、金額/通貨、タイムスタンプ、UTR。
PSP/bankから：クレジット/返品/修正のレジスタ、遅延ステータスの更新。
同期外と「ハング」「保留中」のアラートを設定します。

11） UXプラクティス

モバイルファースト：モバイル-in-app/App2App；デスクトップ上-タイマー付きの大きなダイナミックQR。
回復：'タイムアウト/期限切れ'-安全な再試行と代替（カード/SEPA/他のA2A）。
領収書：金額、時間、'transactionId'、チャネル、UTR、サポート連絡先。
リスク/制限のハイライト：しきい値を設定したユーザー（銀行またはチャネル）を表示します。

12）再発およびマンデート

基本的なTWINTはSCAとのワンオフです。サブスクリプションでは、バンドルが使用されます：最初の支払いTWINT→e-mandition/SEPA DD/Open-Banking for future write-off （limit/frequency/notifications）。
ユーザーに、一時停止/キャンセル/更新および事前通知画面をオフにする前に与えます。

13）高リスク垂直（iGamingを含む）

チャネルの可用性と制限は、銀行/PSPポリシーと現地の法律によって異なります。
下げられたしきい値、高められたKYC、可能な保持を期待して下さい。
代替レール（カード、SEPA、その他のPIS）とリスク/チャネル/銀行によるスマートルーティングを計画します。

14） TWINTゲートウェイアーキテクチャ

キャッシュレジスタとバックホー用のAPIレイヤー（REST/GraphQL）。
イベントキュー：ステータスイベント→課金/CRM/分析。
セキュリティ：秘密の保管庫、IP-allowlist PSP、厳格なリダイレクトURI検証、アンチリプレイトークン。
観測可能性：チャネル変換（App2App/QR/Link）、「保留中→期限切れ」の割合、決済/返却までの時間。

15）出力チェックリスト

1.PSP/bankでTWINTを接続します。チャンネルを選択します（App2App/QR/Link）。
2.'createPayment'/'requestToPay'、動的QR、エラー/制限画面を実装します。
3.Webhook、 idempotency、 retrai、イベントのデッドアップを接続します。
4.recon（毎日+フル）、UTR/fin参照ストレージを設定します。
5.部分的な/完全な払い戻しおよびODRのプロシージャを支えて下さい。
6.変換/レイテンシ/ハングステータスのSLAダッシュボードとアラートを実行します。
7.メインバンク/デバイスとPOSでe2eテストを実行します（関連する場合）。

リミットリファレンスカード

Per-txn/24h/7d： configに保存し、起動前にチェックします。
新しい受信者/商人：しきい値/シャッタースピードを下げました。
チャネル：電子商取引（App2App/QR）、 POS、 P2P、 Request-to-Payのための別の限界。
速度/リスク：銀行のアンチフラウドは、操作を緩やかに偏向/遅くすることができます。

概要

オンライン-in-app/App2App+ダイナミックQR、小売-TWINT QR、転送-電話へのP2P。
別のオンライン確認および最終的な信用；webhooks+reconと部分的な払い戻しを中心にビルドします。
金額を修正しないでください。銀行/チャネルによる制限設定を維持し、定期的に更新します。
サブスクリプションの場合、最初のTWINTバンドル→透明な管理と通知を持つチケット。