2014-05-12 101 views
0

我使用PayPal的REST API進行支付:https://developer.paypal.com/webapps/developer/docs/api/的PayPal API處理返回

的流動本身是很簡單的:

  1. 用戶選擇支付由此產生的支付對象/v1/payments/payment
  2. 用戶被重定向到PayPal認證 (來自PayPal響應對象批准鏈路)
  3. 用戶驗證和 接受
  4. 用戶返回到原始網站
  5. 用戶最終確定支付其觸發 /v1/payments/execute

現在部分我發現有點棘手,是步1-2和4-5。

讓我們從第4部分開始。在從PayPal返回時,URL有PayerIDtoken作爲GET參數。 PayerID是進行交易但不是訂單的用戶的好標識符(如果他們有很多訂單)。因此,token似乎是用來識別訂單的邏輯。

但是......

從創建步驟1中的支付響應只包含在approval_url結束時token這是在嵌套的幾個節點。我已經成功地把它弄出來,並保持備查。這樣它可以用來確定第5步要執行的付款。如果PaymentID在回報中,那將會容易得多。

我想知道我的方法是否準確或是否有更好的方法。當用戶在PayPal過期的情況下轉入PayPal時,我並不完全確定將信息存儲在會話中。

您的想法請。

回答

1

您並不需要存儲令牌,因爲它只能使用一次,並在3小時後過期。取而代之的是,我做的是存儲生成的paymentId:

$_SESSION['paymentId'] = $return['id']; 

當他們重定向到您的着陸頁,你只是檢查,以確保此項設置,如果沒有他們重定向並生成一個新的。您需要paymentId甚至執行付款,或查找有關付款的信息:

POST /v1/payments/payment/{paymentId}/execute 

GET /v1/payments/payment/{paymentId} 

將返回所選擇的送貨地址等

+0

我」什麼我們一直在做的是將'PaymentID'和'token'存儲在數據庫中,然後在返回時使用'token'從數據庫中獲取'PaymentID'。 您已經提到過令牌會在3小時後過期,但默認情況下,會話可能會在24分鐘後過期。 – diggersworld

+0

如果您希望用戶的會話超時,那麼存儲令牌將是交叉引用原始付款的唯一方式。請記住,令牌對將來的任何使用都是無效的。 – Aaron

+0

是的,我收集到了。看起來有點鬆散的結局,無論你使用什麼,會話或令牌。 – diggersworld