Recover from error code 10486

When a buyer's funding source fails, the DoExpressCheckoutPayment and DoAuthorization call, return a 10486 error. If this error occurs, you can redirect the buyer back to PayPal where they can choose an alternate funding source or add a new one.

A funding source may fail for these reasons:

  • The billing address associated with the financial instrument could not be confirmed.
  • The transaction exceeds the card limit.
  • The transaction was denied by the card issuer.

These sections provide further details:

Requirements

You can initiate the recovery process with these Express Checkout implementations:

PaymentAction type API operation
Sale or Authorization DoExpressCheckoutPayment
Order with order ID DoAuthorization

These features do not support the recovery process:

  • Reference Transactions
  • Recurring Payments

Error code details

The Express Checkout error response parameters for the NVP and SOAP API formats are:

API Format Parameter Returned Value
SOAP
NVP
ErrorCode
L_ERRORCODE0
10486
SOAP
NVP
ShortMessage
L_SHORTMESSAGE0
This transaction couldn't be completed.
SOAP
NVP
LongMessage
L_LONGMESSAGE0
This transaction couldn't be completed.
Please redirect your customer to PayPal.

You may redirect the buyer back to PayPal multiple times as long as this error code is returned. Then prompt the buyer to choose another payment method available on your site.

Integration details

Integration details depend on how PaymentAction is set in your implementation. See these sections for integration information when PaymentAction is to:

Sale or authorization integrations

Upon receiving this error code for a sale ora authorization, redirect the buyer back to PayPal using the existing Express Checkout token. On the PayPal page, the buyer is presented with an error message explaining the reason for the decline. Additionally, the buyer is given the option to select an alternate funding source or add a new one. After the buyer changes the financial instrument, you can reattempt the payment.

This diagram shows the redirect flow for DoExpressCheckoutPayment when PaymentAction is set to sale or authorization:

Redirect for sale or authorization failures

Note: This feature makes no changes to the current token expiry period.

Integration steps

Modify your front-end error code handling to redirect the buyer back to PayPal using the same redirect URL that was used to originally start the checkout flow.

This example shows the redirect URL and token:

https://www.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=EC-ABCDE12345

Next, see testing your integration.

Order integrations

Upon receiving this error code for an order, redirect the buyer back to PayPal and include the order ID in the redirect URL. If DoAuthorization is not called immediately or the buyer is not online when the authorization is created, notify the buyer to log in to your website. Then on your website's order review page, present the buyer with an update order button that uses the redirect URL containing the order ID to redirect the buyer back to PayPal. PayPal gives the buyer the option to select an alternate funding source or add a new one. After the buyer successfully changes the financial instrument, you can reattempt sending the payment and completing it successfully.

This diagram shows the redirect flow for DoExpressCheckoutPayment when PaymentAction is set to order:

Redirect for order failures

Note: This feature is not supported for a guest or multi-seller payment.

Integration steps

Modify your front-end error code handling to redirect the buyer back to PayPal using a redirect URL containing the order ID. If you do not call DoAuthorization immediately, or if for another reason the buyer is not online when you are creating the authorization, notify the buyer to log in to your website. Then on your website's order review page, present the buyer with an update order button that uses the redirect URL containing the order ID to redirect the buyer back to PayPal.

This example shows the redirect URL with the order ID:

https://www.paypal.com/cgi-bin/webscr?cmd=_express-checkout&order_id=O-4PS66146G25310203

Modify your back-end code to call DoAuthorization again if the return URL from PayPal contains retry_authorization=true.

Test your integration

The PayPal Sandbox is a self-contained, virtual testing environment that mimics the live PayPal production environment. It provides a shielded space where you can watch your application process calls to the PayPal APIs, without touching any live PayPal accounts. By substituting fictitious sandbox accounts and their associated authentication credentials in your PayPal API calls, you can test and debug your application without referencing any real PayPal users or their PayPal accounts. To set up your sandbox test environment, see the PayPal Sandbox Testing Guide.

To test your error-handling code, configure a fictitious Sandbox buyer's PayPal account to return error 10486 when it is used to execute an Express Checkout payment in the Sandbox environment.

Test a sale or authorization integration

  1. Log in to https://www.sandbox.paypal.com using your buyer's test PayPal account.
  2. Replace the contents of the street address Line-1 of the buyer's test credit card, with CCREJECT-REFUSED.
  3. Execute a typical Express Checkout payment flow against the sandbox environment using the same buyer account and with the same credit card that you just modified.
  4. When you execute DoExpressCheckoutPayment, error code 10486 is returned. Your code should redirect the buyer back to PayPal using the same redirect URL used to start the checkout flow and the same Express Checkout token.

Test an order integration

  1. Log in to https://www.sandbox.paypal.com using your buyer's test PayPal account.
  2. Replace the contents of the street address Line-1 of the buyer's test credit card, with CCREJECT-REFUSED.
  3. Execute a typical Express Checkout payment flow against the sandbox environment using the same buyer account and with the same credit card that you just modified.
  4. Execute DoExpressCheckoutPayment with the token and passing the PayerID.
  5. When you execute DoAuthorization on the order ID, error code 10486 is returned.
  6. Redirect the buyer back to PayPal using a redirect URL containing the order ID. For example: https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_express-checkout&order_id=O-4PS66146G25310203. If you do not call DoAuthorization immediately, or if the buyer is not online when you create the authorization, notify the buyer to log in to your website. Then on your website's order review page, present the buyer with an update order button that uses the redirect URL containing the order ID to redirect the buyer back to PayPal.
  7. After the buyer successfully updates their funding options on PayPal, the buyer is returned to your website. The return URL will contain the order ID and the field retry_authorization=true. For example, http://www.yourURL.com/return.html?order_id=O-9X380895SN0698611&retry_authorization=true. retry_authorization=true indicates that the buyer updated his / her funding source successfully. Your code should call DoAuthorization again for this order ID.

The buyer's experience

When the buyer returns to PayPal, they are prompted with proper error messaging on the PayPal page. If the buyer's PayPal login session is still active, they do not need to log in again.

For example, the buyer may see an error message similar to this on the PayPal page:

We're sorry, but your transaction couldn't be completed using the selected card, Visa x-1234, because it has been denied by the card issuer. Another payment method has been chosen for you. Please continue with this payment method, or choose a different way to pay.

Option 1

This example shows the buyer is asked to choose another payment method, if one is available:

Option 2

This example shows the buyer is prompted to add a new funding source if an alternative funding source is not available:

Additional information