| « PreviousNext » | |
  | Did this page help you? Yes | No | Tell us about it... |
Handling Transactions that Don't Return
When a customer buys a product on your website, their expectation is that the product will be paid for and delivered, but sometimes problems cause service requests to become lost. In those cases, it is sometimes possible to find the lost transaction.
Co-Branded service Requests that Don't Return
After the sender finishes the CBUI pages and authorizes the payment, the service should
redirect the sender to the URL you specified in the returnURL parameter
in the Co-Branded service request. There are times, however, when the sender authorizes the
payment or contract and the redirect fails. Because you do not have the
fundingtokenID for prepaid, or
creditSenderTokenID for postpaid you cannot charge the sender for the
authorized purchase. Use the following procedure when the redirect from the Co-Branded service
fails.
To recover the Prepaid or Postpaid Payment Token (Sender Token)
Retrieve from your records the
CallerReferenceyou supplied in the Co-Branded service request for the transaction in question.You do this by querying your database.
Send a
GetTokenByCallerrequest where you supply theCallerReference.For more information, see GetTokenByCaller.
If there isn't an
Errorsparameter in the response, the sender authorized the payment but there was some problem with the redirect toreturnURL. The response includes theprepaidSenderTokenIDfor prepaid, orcreditSenderTokenIDfor postpaid.If there is an
Errorsparameter in the response, the transaction did not succeed.
Resending Requests
There are times when network problems prevent the completion of requests. This could happen both for Co-Branded service requests and for FPS API requests. Your application should periodically check for this condition, and if it occurs, retry the request.
Resending Co-Branded Service Requests
To check for Co-Branded service requests that didn't complete, whenever you send a request, put the caller reference value from the request in your database. When you get the response, store the token ID that your receive against the caller reference in your database.
About once each hour, resend any requests that don't have a sender token ID stored against the caller reference. The timing is important, because for most tokens, Amazon FPS maintains the token IDs for only three hours.
Resending Amazon FPS API Requests
Each time you send a request to the Amazon FPS API, FPS maintains the caller reference from the request for 7 days and uses it to check for duplicate requests. If you don't receive a response to an Amazon FPS API request, you can resend the exact same request within that seven-day period, and Amazon FPS will return the original response and not create a new transaction. If the first request succeeded, the second request does not charge the sender's payment instrument a second time.
In that seven-day period, if you send a request with that same caller reference value but other parameter values, Amazon FPS returns a DuplicateRequest error.
After the seven-day period, if you send the original request again (with the same caller reference and parameter values), Amazon FPS creates a new transaction.
