現在、SMSを使用して、または番号に電話をかけてサービスの支払いを行うために、zaypayに支払いプロバイダーを実装しようとしています。私たちはすでにグーグルチェックアウトとペイパルが定期的な支払いのために働いていますが、zaypayはかなり柔軟性がなく、文書化が不十分で、価格が異なる何百もの製品がある場合はセットアップが面倒です。
だから私の質問は、SMSを受け取って支払いを呼び出す他のヨーロッパの支払いプロバイダーを知っていますか？
ロバーツの回答/質問への回答として
こんにちはロバート、私はZaypayソリューションが最高であり、電話による支払いに関してこれまでに見たのは私だけだと言わなければなりません。ただし、2か月前にカスタムZaypay UIの実装を終了して以来、発生していた問題の詳細の多くを思い出せません。とにかく私ができる限りそれらの簡単な説明をしようとします。
まず、payalogueのリダイレクトタイプのシナリオを見てみたいと思います。私が覚えていることから、皆さんは私たちが使用しているjQueryとうまく機能しないJSフレームワーク「Prototype」を使用しているため、payaloguesでサポートされているポップアップタイプのシナリオを使用できませんでした。
さらに、カスタムインターフェイスを実装するときに、単語やフレーズではなくコードである単語など、多くの欠落した翻訳を覚えています。これは、私たちが自分たちで必要とするすべてのメッセージを書く/翻訳することになったということを意味しました。
また、もう一つの悩みの種は、価格とアイテムの設定でした。Google CheckoutやPayPalのように、インターフェースの一部として注文アイテム/価格を送信できればいいのですが（完璧ではありません）、これまでに販売するすべてのアイテムを定義する必要はありません。事前に管理インターフェース。私が覚えている限り、現在の形式で複数アイテムの注文にZaypayを使用することは事実上不可能です。
最後に、私が知る限り、カスタムソリューションを実装するときに考慮しなければならないセキュリティの問題がいくつかあります...特にajax駆動のソリューションです。私の元の投稿で述べたように、ドキュメントでこれについて言及していますが、ドキュメントはセキュリティの問題に関してそれほど包括的ではなかったと思います。繰り返しになりますが、詳細をお伝えしたいのですが、コードとクライアントがなくなってから長いので、書いたコメントを調べることができません。ごめん！
そうそう、一般的なAPIドキュメントは正確に包括的ではなく、100％正確でもありませんでした。
繰り返しになりますが、Zaypayを使用しないように人々にアドバイスしたくありません。競合するJSフレームワークを使用しない場合、payalogueは非常に簡単に実装できるようです。Zaypayを検討している人は、最初に現実的なプロトタイプで試してみて、カスタムインターフェイスを実装している場合は、本番環境にリリースする前に実装について検討する必要があることをアドバイスしたいと思います（これはお勧めできません）。
多くのことを誤解したのは私だけかもしれませんが、一般的にフレームワークを使用するのに苦労し、APIは非常に新しく、最初から考え抜かれていないと感じました。