appアクセスアリペイ支払い機能の詳細とピット
4363 ワード
appアクセスサードパーティ支払のアリペイチュートリアルアリペイオープンドキュメントリンク
ここでは詳細についてお話しします
まず、アリペイsdkをダウンロードして、私たちのプロジェクトに直接導入すればいいので、この操作は多くありません.
ここで私が封印した支払い方法の一つはMessageオブジェクトで、注文番号を伝える必要があります.このように封印するのは、私たちが支払いを呼び出すときに便利に呼び出すためです.私たちの支付宝は微信とは違って、支付宝は砂箱環境をサポートしています.特にこのコードが必要な場合、EnvUtils.setEnv(EnvUtils.EnvEnum.SANDBOX); もしあなたが砂箱環境を使ってこのコードを追加するならば、もしあなたが正式な環境ならばこのコードを注釈して、さもなくば呼び出すと問題が発生して、もちろんあなたがここを移動して砂箱環境を開いたら、相応のバックグラウンドが戻るパラメータも相応の変化があることに注意します.だからここではバックグラウンドとあなたたちがどんな環境なのかをコミュニケーションする必要があります.砂箱なら砂箱を統一し、正式なら正式に統一します.
私たちはmsgオブジェクトを手に入れた後、直接非同期呼び出しをします.ここでは必ずサブスレッドを開いて、情報を送信すればいいです.次にappは支付宝を呼び起こし、残りはコールバックを受信します.
公式に与えられた呼び出しコードと私が与えたものを比較して理解してみましょう.書き方は違いますが、論理は同じです.
#####アリペイコールここで注意しなければならないのは、サブスレッドでHandlerオブジェクトを使用していることです.では、このHandlerオブジェクトはどこから来たのか、答えはここです.必ずこのオブジェクトを使用しなければなりません.そうしないと、コールバックを受信できません.ここで、返されるステータスコードが9000であれば、支払いが成功したことを示し、そうでなければ支払いが失敗し、支払い失敗はそれぞれ対応する処理を行う.私のところ支付宝が失敗したのは閉鎖前の活動で、新しい注文活動を開きました.ここでは、閉じたいアクティビティを閉じるのに便利なアクティビティ管理フレームワークを使用しています.アクティビティがオフの場合、フレームワークはこのアクティビティの参照を保持しません.
以上が支払いプロセス全体です.では、ここでもう一つの問題は注文番号です.公式ドキュメントを見に行くと、宝の要求パラメータが山積みになりますが、モバイル端末が開発した場合は、パラメータを管理する必要はありません.すべてのパラメータはバックグラウンドで計算され、モバイル端末は直接注文番号を手に入れて支付宝を呼び出すことができます.
最後に全体の支払いロジックを簡単に説明すると、appIdなどのすべての要求パラメータはバックグラウンドで処理しなければならないので、注文番号の計算もバックグラウンドで負担されます.これも安全のためです.次に私达の1つの支払いの検证で、あなたがモバイル端末が支払いに成功した时、あなたのモバイル端末は1つの支付宝の成功のコールバックを受け取って、バックグラウンドもできて、それではこの时あなたはあなたのモバイル端末が受け取った支付宝の成功を基准にしないでください、あなたがモバイル端末が仕事のコールバックを支払った后にバックグラウンドに行って支払いに成功するかどうかを寻ねるべきで、もし成功に戻ったら今回の支払いはやっと成功します.それ以外の場合、1回の失敗は失敗処理となります.次に、返金モバイル側は対応するリクエストを送信するだけで、具体的な返金ロジックはサーバが担当し、どの注文が返金される必要があるかを伝えるだけです.もちろんあなたも恐れないでください、もしあなたがモバイル端末の支払いに成功したら、バックグラウンドは知りませんが、彼は本当に支払いに成功して、彼のお金はなくなりました.この小さな確率の問題は、第一にあなたの家のカスタマーサービスに連絡して解決することができます.支付宝の向こうは請求書ですから、第二にあなたのサーバーに請求書を同期させて相応の支払い記録を検査して、返金操作を行うことができますが、一般的に第一種類を選択して、結局とても小さい確率の事件です.
好きならいいですね.ありがとうございます.次号は微信アクセスガイドを更新します.
ここでは詳細についてお話しします
まず、アリペイsdkをダウンロードして、私たちのプロジェクトに直接導入すればいいので、この操作は多くありません.
ここで私が封印した支払い方法の一つはMessageオブジェクトで、注文番号を伝える必要があります.このように封印するのは、私たちが支払いを呼び出すときに便利に呼び出すためです.私たちの支付宝は微信とは違って、支付宝は砂箱環境をサポートしています.特にこのコードが必要な場合、EnvUtils.setEnv(EnvUtils.EnvEnum.SANDBOX); もしあなたが砂箱環境を使ってこのコードを追加するならば、もしあなたが正式な環境ならばこのコードを注釈して、さもなくば呼び出すと問題が発生して、もちろんあなたがここを移動して砂箱環境を開いたら、相応のバックグラウンドが戻るパラメータも相応の変化があることに注意します.だからここではバックグラウンドとあなたたちがどんな環境なのかをコミュニケーションする必要があります.砂箱なら砂箱を統一し、正式なら正式に統一します.
public Message create(Activity activity){
//
//EnvUtils.setEnv(EnvUtils.EnvEnum.SANDBOX);
WeakReference wr = new WeakReference(activity);
PayTask alipay = new PayTask(wr.get());
Map result = alipay.payV2(out_trade_no, false);
Message msg = new Message();
msg.what = 1;
msg.obj = result;
return msg;
}
私たちはmsgオブジェクトを手に入れた後、直接非同期呼び出しをします.ここでは必ずサブスレッドを開いて、情報を送信すればいいです.次にappは支付宝を呼び起こし、残りはコールバックを受信します.
Model.getInstance().getGlobalThreadPool().execute(new Runnable() {
@Override
public void run() {
handler.sendMessage(new ZFBPayUtils(prepayid).create(activity));
}
});
公式に与えられた呼び出しコードと私が与えたものを比較して理解してみましょう.書き方は違いますが、論理は同じです.
final String orderInfo = info; //
Runnable payRunnable = new Runnable() {
@Override
public void run() {
PayTask alipay = new PayTask(DemoActivity.this);
Map result = alipay.payV2(orderInfo,true);
Message msg = new Message();
msg.what = SDK_PAY_FLAG;
msg.obj = result;
mHandler.sendMessage(msg);
}
};
//
Thread payThread = new Thread(payRunnable);
payThread.start();
#####アリペイコールここで注意しなければならないのは、サブスレッドでHandlerオブジェクトを使用していることです.では、このHandlerオブジェクトはどこから来たのか、答えはここです.必ずこのオブジェクトを使用しなければなりません.そうしないと、コールバックを受信できません.ここで、返されるステータスコードが9000であれば、支払いが成功したことを示し、そうでなければ支払いが失敗し、支払い失敗はそれぞれ対応する処理を行う.私のところ支付宝が失敗したのは閉鎖前の活動で、新しい注文活動を開きました.ここでは、閉じたいアクティビティを閉じるのに便利なアクティビティ管理フレームワークを使用しています.アクティビティがオフの場合、フレームワークはこのアクティビティの参照を保持しません.
private Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
switch (msg.what){
case 1:
//
PayResult payResult = new PayResult((Map) msg.obj);
/**
* , 。 , 。
*/
String resultInfo = payResult.getResult();//
String resultStatus = payResult.getResultStatus();
// resultStatus 9000
if (TextUtils.equals(resultStatus, "9000")) {
// , 。
//System.out.println(" ");
OrderQuery(orderid);
} else {
// , 。 ........
AppManage.getInstance().clearActivitys("TouristsDetailsActivity","TouristsOrderFormActivity");
}
break;
}
}
};
以上が支払いプロセス全体です.では、ここでもう一つの問題は注文番号です.公式ドキュメントを見に行くと、宝の要求パラメータが山積みになりますが、モバイル端末が開発した場合は、パラメータを管理する必要はありません.すべてのパラメータはバックグラウンドで計算され、モバイル端末は直接注文番号を手に入れて支付宝を呼び出すことができます.
最後に全体の支払いロジックを簡単に説明すると、appIdなどのすべての要求パラメータはバックグラウンドで処理しなければならないので、注文番号の計算もバックグラウンドで負担されます.これも安全のためです.次に私达の1つの支払いの検证で、あなたがモバイル端末が支払いに成功した时、あなたのモバイル端末は1つの支付宝の成功のコールバックを受け取って、バックグラウンドもできて、それではこの时あなたはあなたのモバイル端末が受け取った支付宝の成功を基准にしないでください、あなたがモバイル端末が仕事のコールバックを支払った后にバックグラウンドに行って支払いに成功するかどうかを寻ねるべきで、もし成功に戻ったら今回の支払いはやっと成功します.それ以外の場合、1回の失敗は失敗処理となります.次に、返金モバイル側は対応するリクエストを送信するだけで、具体的な返金ロジックはサーバが担当し、どの注文が返金される必要があるかを伝えるだけです.もちろんあなたも恐れないでください、もしあなたがモバイル端末の支払いに成功したら、バックグラウンドは知りませんが、彼は本当に支払いに成功して、彼のお金はなくなりました.この小さな確率の問題は、第一にあなたの家のカスタマーサービスに連絡して解決することができます.支付宝の向こうは請求書ですから、第二にあなたのサーバーに請求書を同期させて相応の支払い記録を検査して、返金操作を行うことができますが、一般的に第一種類を選択して、結局とても小さい確率の事件です.
好きならいいですね.ありがとうございます.次号は微信アクセスガイドを更新します.