タグのリストにDjangoが存在することを正当化するために、フレームワーク自体は以前の内部開発で使用されていましたが、これがDjangoでの最初のパブリックプロジェクトであることに注意してください。
コードを1行も書かずに、当社のWebサイトに登録せずに、すべてのお金を事前に受け取ることなく、SMS支払いをリソースに接続する方法に興味がある場合は、先に進んでください。
このプロジェクトについての話は、特定の背景から始める価値があります。 かつて、私たちはSMSサービスを提供しました：安全なタスクは、特定の国で利用可能な最大関税を超える金額のSMSを支払うための指示を生成することでした（誰も知らない場合、最大支払い額は非常に限られており、各国で異なります）。 したがって、パートナーが5ドルを取得したい場合、サービス設定で、ドロップダウンメニューでいくつかのSMSを送信する支払いオプションを選択する機会がありました。その合計費用は所望の合計金額に最も近いです。 たとえば、2ドルの場合は3 sms、0.9ドルの場合は5 smsを選択できます。 重要な条件は、支払い時のすべてのSMSのコストが同じであることです。 実際、料金に送信するSMSの数を掛けただけです。
このサービスはいくつかの理由で人気がありませんでした。 これは、作業スキーム、統合の非自明なスキーム、およびコストに合うスキームの制限の難しさです（2ドルで2 sms、0.9ドルで1 smsを作成し、上記の例から金額を取得することは不可能でした）。より正確な量または少数のSMSですが、量は望みとはほど遠いです。 その結果、サービスを凍結し、パートナーには提供しないという決定に至りました。
それは多分、需要は残ったままであり、パートナーの一部は彼らの側でこの論理を実装することができましたが（神に感謝します、私たちはすべての関税を輸出しています）、多くは何らかの理由で私たちがそのような解決策を提供することを期待していました。 ご存知のように、需要は供給を生み出し、1年前に私たちはサービスの新しいバージョンを別のプロジェクトとして思いついてすぐに実装しました。
今回、私たちはさらに先に進んで、売り手の「濡れた夢」を実現することを決めました。何もせず、商品のお金を事前に得る。 これを行うには、製品とその価値という2つの単純なものが必要でした。 商品については、売り手がサービスに提供したバウチャーを受け取るか、残高を補充するかが決定されました。 PINコード、ログインパスワード、またはアクティベーションリンクのいずれかです。 このメカニズムは、ファイル共有サービスまたはソーシャルネットワークで広く使用されています。 AppleはこれらのバウチャーをiTunesに用意しており、以前はSkypeを使用していました。 言い換えれば、バウチャーはキャッシュフローのかなり一般的な方法であり、多くの一般的なサービスで機能します。
一般に、製品とその価格（販売者が決定します）を決定しました。 技術的な部分を改良するために残った。 開発には、以前使用されていたDjangoを選択しました。 このプロジェクトの開発者にとって、これが最初であり、一般に成功した経験であったことは注目に値します（プロジェクトは機能し、お金をもたらします）。 技術的な観点から、SmsCoinが提供するすべての自動化機能と、選択した国と金額をパラメーターとして考慮し、ユーザーへの指示を作成するデータの配列を発行する機能によって自動的に生成される指示を使用することが決定されました。 元のSMSサービスとは異なり、安全で異なる料金を組み合わせることができますが、主な目標は送信されるSMSメッセージの数を減らすことです。
ある支払いと別の支払いを区別するために、ユーザーに対して一意のメッセージテキストが生成され、このテキストを含むすべてのSMSがユーザーの支払いに添付されます。 SMS支払いの分野でよくある詐欺のケースを避けるために、すべてのSMSは同じ国から、原則として同じ番号から送信する必要があります。 ユーザーが既に支払った金額と残額を明確に知るために、SMSを受信すると、指示のステータスが「期待」から「受信」に変わります。 そして一般的に、全体の指示はシンプルで理解しやすいものです。 サブスクライバーがすべてのSMSメッセージを一度に送信するのに十分なお金がなく、残高を補充する必要がある状況が発生する可能性があるため、トランザクションの時間を制限しないことにしました。 ユーザーが開いているトランザクションに戻るか、以前に受信したコードを再表示できるように、トランザクションを検索する機能を追加することにしました。
その結果、 smspay4.comという単純な名前の非常に興味深いプロジェクトができました 。 エンドユーザーにとって、インターフェースは絶対に最小限です。支払い指示、フィードバックフォーム、トランザクション表示フォーム。 迷子になる場所はありません。支払いを成功させる方法は1つしかありません。
売り手にとって、このプロジェクトはさらに興味深いものになりました。 どこにも登録する必要はありません（原則、場所はありません）-販売者のウェブサイトで登録するだけです（まあ、またはメールで連絡します）。 統合プロセス全体では、販売者のプロジェクト専用に作成された支払いページへのリンクを追加します。 金融決済も主に前払いで行われます。 最初にバウチャーを支払い、購入します。バウチャーが販売されるとき、それは私たちの関心事であり、売り手はすでに彼のお金を受け取っています。
その結果、原則として、ささいな論理と理解可能な実装が、かなり興味深い販売スキームを備えたプロジェクトの基礎を形成し、サービスの大部分に完全に適しており、それらからのアクションをまったく必要としません。 以前にすべてを明確にするために、このスキームに従って作業するプロジェクトのいずれかの支払いページへのリンクを提供します-smspay4.com/project/hotfile
プロジェクトは単純なものになりました（少なくともユーザーに見える部分）が、指定された要件を完全に満たしています。 私たちが知る限り、競合他社の誰もそのような解決策を持っていません。これも素晴らしいです:-)。 協力に興味がある人は、PMに手紙を書くか、サイトの連絡先に連絡してください。