PayPal PayFlow Pro ゲートウェイを介して支払いを処理するクライアントがいます。
ほとんどのトランザクションは Web サイト経由で行われ、トランザクションをログに記録し、サイトの管理ツールでレポートを提供します。
ただし、クライアントが仮想端末に直接ログインして手動トランザクションを追加し、払い戻しを行う場合があります。そのため、サイトのトランザクション ログは、ゲートウェイを介して送信されたトランザクションの実際の状態を必ずしも反映しているわけではありません。
さらに、クライアントがレポートを実行したい製品カテゴリがいくつかあります。サイトのトランザクション ログが不正確であるため、クライアントはこのレポートを仮想端末で実行したいと考えています。
これに対する解決策は、カテゴリごとに個別のアカウントを作成し、カテゴリごとのトランザクションを適切なアカウントに送信することでした。
私の同僚の理想的とは言えない実装は、一度に複数のカテゴリのアイテムをカートに追加できないようにすることでした。ユーザーは、2 つの別々のチェックアウトを行うように指示されました。
カテゴリが 2 つしかなかったときは、これはほとんど許容できませんでしたが、現在では 3 つになります。
クライアントが提案する解決策は、カート内でカテゴリを混合できるようにすることから始めますが、バックエンドではそれらを分割し、チェックアウト時にカテゴリごとに「インライン」で個別のトランザクションを送信することです。
ご想像のとおり、私はこの方法が好きではありません。途中で何かがうまくいかず、レジが中途半端な状態で残ってしまうのではないかと心配です。さらに、それは会計の悪夢のように聞こえます。
私は、PayFlow Pro がある種の「項目」機能を提供し、適切なレポート機能を提供することを望んでいました。
彼らの XML API は明細項目をサポートしているようで、これはレベル III のトランザクション用だと思います。ただし、仮想端末にログインすると、レベル III のデータはサポートされていないようです。さらに、これはレベル III が意図したものではなく、「方向性に逆らっている」と感じています。
そこで、ここで選択肢を検討しています。これまでに検討したのは次の 2 つです。
Web アプリでアドホック トランザクションの作成、払い戻しの発行などの機能を提供し、これらの変更は Web アプリからのみ行うことができるというルールを作成します。そうすれば、これらのトランザクションをログに記録し、より正確なレポートを提供できます。ただし、これは大変な作業になります。
おそらく、PayPal の世界には、バックエンドでより豊富な API とレポート機能を提供するものがあるでしょう。既存のマーチャント アカウントをサポートできる必要があります。彼らの料金が上がった場合、それは彼らが望むものを手に入れるための合理的なトレードオフになるでしょう.
一般に、PayPal の製品提供は私にとって非常に混乱するため、オプション B が存在するかどうかを教えてくれるのに十分なほど PayPal を理解している人がいるかどうかを尋ねます。さらに、誰かが一般的なアドバイスを持っている場合、または CI が考慮していないオプションがある場合。
ありがとう。