1.簡單點說就是呼叫支付寶那邊的介面方法，然後傳遞資料過去，之後會返回乙個是否成功的值，然後你拿到之後判斷就好了
流程說明（以android平台為例）：
第4步：呼叫支付介面：此訊息就是本介面所描述的開發包提供的支付物件paytask，將商戶簽名後的訂單資訊傳進pay方法喚起支付寶收銀台，訂單格式具體參見「請求引數說明」。
第5步：支付請求：手機支付寶支付開發包將會按照商戶客戶端提供的請求引數傳送支付請求。
第8步：介面返回支付結果：商戶客戶端在第4步中呼叫的支付介面，會返回最終的支付結果（即同步通知），參見「同步通知引數說明」。
第12步：非同步傳送支付通知：手機支付寶支付伺服器端傳送非同步通知訊息給商戶伺服器端（備註：第12步一定發生在第6步之後，但不一定晚於7~11步），參見「伺服器非同步通知引數說明」。
構造訂單資料並簽名
商戶伺服器端根據手機支付寶支付開發包的介面規則，通過程式生成得到簽名結果及要傳輸給手機支付寶支付開發包的資料集合。簽名相關的公私鑰生成及配置規則，見pid和金鑰管理。
傳送請求資料
把構造完成的資料集合傳遞給手機支付寶支付開發包。
手機支付寶支付開發包對請求資料進行處理
手機支付寶支付開發包將請求資料根據業務規則包裝後傳遞給手機支付寶支付伺服器端，伺服器端得到這些集合後，會先進行安全校驗等驗證，一系列驗證通過後便會處理完成這次傳送過來的資料請求。
返回處理的結果資料
對於處理完成的交易，支付寶會以兩種方式把資料分別反饋給商戶客戶端和商戶伺服器端。在手機客戶端上，手機支付寶支付開發包直接把處理的資料結果反饋給商戶客戶端；
在伺服器端上，手機支付寶支付伺服器端主動發起通知，呼叫商戶在請求時設定好的頁面路徑（引數notify_url，如果商戶沒設定，則不會進行該操作）。
商戶對獲取的返回結果資料進行處理
商戶在客戶端同步通知接收模組或伺服器端非同步通知接收模組獲取到支付寶返回的結果資料後，可以結合商戶自身業務邏輯進行資料處理（如：訂單更新、自動充值到會員賬號中等）。同步通知結果僅用於結果展示，入庫資料需以非同步通知為準。名詞解釋：請求
手機客戶端以字串形式把需要傳輸的資料傳送給接收方的過程。
返回支付寶以字串形式直接把處理結果資料返回給手機客戶端。
通知伺服器非同步通知。支付寶根據得到的資料處理完成後，支付寶的伺服器主動發起通知給商戶的**，同時攜帶處理完成的結果資訊反饋給商戶**。
支付寶對商戶的請求資料處理完成後，會將處理的結果資料直接通知給商戶。這些處理結果資料就是同步通知引數。
同步返回的資料，對於商戶在服務端沒有收到非同步通知的時候，可以依賴服務端對同步返回的結果來進行判斷是否支付成功。同步返回的結果中，sign欄位描述了請求的原始資料和服務端支付的狀態一起拼接的簽名資訊。驗證這個過程包括兩個部分：1、原始資料是否跟商戶請求支付的原始資料一致（必須驗證這個）；2、驗證這個簽名是否能通過。上述1、2通過後，在result欄位中success=true才是可信的。【特別注意，同步結果校驗的邏輯，必須放在服務端處理，切記不要放在客戶端】【強烈建議商戶直接依賴服務端的非同步通知，忽略同步返回】
說明：這裡的規則僅限於接入sdk支付模式，對於純粹的wap瀏覽器接入的模式不適用，也就是只針對簽約mobile.securitypay.pay這個服務的業務適用，瀏覽器模式，建議走非同步通知的方式。
支付寶介面
支付寶的介面呼叫很不方便，剛做好乙個封裝，實現了虛擬交易和實物交易。解決方案中有三個專案以及ndoc生成的文件，簡單的序列圖 commonalipay，封裝的支付寶介面。testali,asp.net的測試專案 testcommonalipay，nunit的測試專案。呼叫方法 1 引入commona...
支付寶介面
解決方案中有三個專案以及ndoc生成的文件，簡單的序列圖 commonalipay，封裝的支付寶介面。testali,asp.net的測試專案 testcommonalipay，nunit的測試專案。呼叫方法 1 引入commonalipay.dll 2 實現支付寶服務介面的方法呼叫方式 alipa...
支付寶介面
解決方案中有三個專案以及ndoc生成的文件，簡單的序列圖 commonalipay，封裝的支付寶介面。testali,asp.net的測試專案 testcommonalipay，nunit的測試專案。呼叫方法 1 引入commonalipay.dll 2 實現支付寶服務介面的方法呼叫方式 alipa...