あなたのやり方は間違っていますが、実際には、提案された 2 つの解決策で説明したよりもはるかに簡単です。
まず、カード タイプの包括的なリストを取得することはできません。私は長年にわたってクレジット カード処理ソフトウェアを作成してきましたが、最高のプロセッサは、プロセッサごとの一般的なリストを提供することです。彼らが提供するリストは、通常、消費者レベル 1 カードまたはレベル 2 または 3 カードのバリエーション (フリート、P カードなど) としてカードを分類するだけです。そのため、決済で明細の詳細を送信する場合を除き、これに対処する必要はありません。(私を信じてください、あなたはそれに対処したくありません....それは純粋な混乱です。)
あなたがする必要があるのは、情報の配信時に資金を承認保留にするプロセスを用意することです. これにより、カードの所有者がカードに費やすことができる金額が差し引かれ、回収できるように予約されます。あなたがそのホールドを持っている間、あなたがお金を集めるのに問題があることはまずありません. これは事前承認ではありません。事前承認は、カードが有効であるという一般的な考えを提供するだけで、後で回収するための資金を確保するものではありません.
次に、お金を集める方法は2つあります。
- ホスト キャプチャを実行するプロセッサを使用します。これは、1 日の特定の時間に、すべての未処理の承認が自動的に決済されることを意味します。これは、承認時に電子情報を配信する場合に最適です。
- プロセッサに決済用のトランザクションを送信する独自の日常的なプロセスを用意します (ターミナル キャプチャとも呼ばれます)。この方法を使用すると、購入した商品の配送が遅れる可能性がある場合に、いつお金を回収するかを決めることができます。(たとえば、購入したアイテムを製造する必要があるかもしれません。)
どちらの方法でも、顧客は好きな種類のカードを使用でき、購入品が配達されて初めて請求されます。彼らは購入後すぐにカードをキャンセルすることもできますが、あなたが彼らの資金に置いた OTB (購入可能) に対する予約を回避することはできません. そのため、バーチャル カードやキャッシュ カードを使用した場合でも、予約の金額を差し引いた金額しか引き出すことができません。
そして、一般に信じられていることとは反対に、クレジット カード番号を保存できます。これは、PCI コンプライアンスのハードルが高いことを意味します。あなたの場合、トークン化ソリューションはこのバーを少し下げるかもしれません. これを提供するプロセッサはいくつかありますが、それは別のスレッドでの長い議論です。