混乱が始まる場所であるショッピングカートが必要になるプロジェクトがあります。私たちが考えている支払いゲートウェイは多くのカートをサポートしていますが、それは私が自分でカスタムカートを作成できないことを意味しますか？約10個の商品を販売しているので、クライアント向けにカスタマイズされたカートを作成したいと思っていました。
これはPHP/MySQLサイトであり、これは私の最初のeコマースプロジェクトであり、カスタムカートを作成すると、ゲートウェイにリンクできなくなるのではないかと心配しています。私はただ妄想的ですか？
それはゲートウェイと物事がどのように渡されるかに依存します。
一般に、支払いゲートウェイが複数のカートをサポートしている場合、それにリンクするための技術的な方法がありますが、APIの詳細（アイテム、数量、税金、配送情報などを渡す方法など）が必要になります。 ）。
最悪の場合、サポートされているカートがどのようにそれを実行し、機能を複製するかを確認できます。
情報を探すのに最適な場所は、支払いゲートウェイ自体です。SDKやAPIをさまざまな言語で提供している場合もあります。もちろん、これはすべて、支払いゲートウェイがカスタムソリューションを使用できるようにすることを前提としています（ほとんどは）
電子商取引は開発のリスクが高い領域であり、本番環境で使用する前に、自分が何をしているのかを確実に理解する必要があることを指摘しておきます。過充電/過少課金、SQLインジェクション攻撃などを引き起こす可能性のあるバグ/欠陥がコードにないことをできる限り確認する必要があります。
サポートされているカートのいずれかがオープンソースである場合、そうです、あなたは少しパラノイアです。ゲートウェイがどのように物を渡すことを望んでいるかを確認するために、それらのいずれかの支払いモジュールをかなり簡単に見ることができます。それに加えて、ゲートウェイは通常、どのように何かを期待するかを文書化します。これは、通常、これらのオープンソースモジュールが最初に作成される方法です。
そうは言っても、これが初めてのeコマースサイトである場合は、既存のカートから始めて、多くの問題を回避することをお勧めします。クレジットカードの情報や一般的なお金を扱うときは、心配することがたくさんあり、従うべきルールがあります。証明されていないコードが悪用されるのを待っているのは望ましくありません。大きな確立されたカートはしばらくの間そこにあり、完全に間違ったことをしている可能性は低いです。
支払いプロバイダーは通常、お金を処理する際のセキュリティ面を処理します。すべてのトランザクションにSSLを使用していることを確認してください。
そうは言っても、そこには多くのカートの実装があります。小さく始めても成長するかもしれないので、私は通常これらを好みます。既存の実装では、独自のスケーラビリティではなく、このスケーラビリティが提供されます。カスタム実装によって顧客の差別化を図る予定がない限り、既成のものを使用してください。