Discontinue Use of GET Method for Classic NVP/SOAP APIs

PayPal will no longer support the use of the GET HTTP request method for our classic NVP/SOAP APIs. If you currently use any of these APIs, you will need to ensure that your API requests only use the POST HTTP request method.

Merchant Security Roadmap

The information that follows is of a highly technical nature and should be reviewed by one of the following:

Your web hosting company
Your e-commerce software provider
Your in-house web programmer/system administrator

In a Nutshell...

PayPal currently accepts both GET and POST HTTP methods on our classic NVP/SOAP APIs, used for Express Checkout, Website Payments Pro, MassPay and Button Manager. Starting from June 2018, PayPal will only allow the use of the POST request method for these APIs. This change will not impact the behaviors of our other API products, such as REST and Adaptive APIs.

To avoid any disruption of service, you must verify that your systems are ready for this change by June 2018.

To help merchants understand the areas of their integration that still require work we will conduct brief rounds of testing in April to demonstrate the upgraded security experience. For information, click Here.

What do I need to do?

Technical Details

About Classic NVP/SOAP APIs

In most cases, PayPal’s classic APIs are integrated using either the Name-Value Pair (NVP) or Simple Object Access Protocol (SOAP) protocol and use PayPal’s api* endpoints (e.g., “api-3t.paypal.com”). These NVP/SOAP APIs are used for Express Checkout, Website Payments Pro, MassPay and Button Manager. You can identify if a request is using an NVP/SOAP API by looking at the URL used for the request to see if it matches these criteria:

Does it use one of the following endpoints?
- api.paypal.com
- api-aa.paypal.com
- api-3t.paypal.com
- api-aa-3t.paypal.com
For NVP-based APIs:
- Does it have a URL structure of *.paypal.com/nvp/?
- Does it contain METHOD, USER, and PWD parameters in the request?
For SOAP-based APIs:
- Does it have a URL structure of *.paypal.com/2.0/?
- Does it contain a SOAP-ENV:Header with a Credentials element that has Username and Password elements?

For more details, including a full list of API operations, see the FAQs below, as well as the NVP and SOAP API Reference documentation on the Developer Portal.

Temporary Sandbox Endpoints - Ready Now

PayPal has created new, temporary Sandbox endpoints that have been configured with the latest security standards to which the Sandbox and Production endpoints will be moving. You can use these temporary endpoints to verify that your code supports the required standards prior to the Sandbox endpoints getting updated:

test-api.sandbox.paypal.com
test-api-3t.sandbox.paypal.com

These endpoints will be available until September 30, 2016.

Sandbox Endpoints - Ready after June 17, 2016

The Sandbox environment will only allow the use of the POST method for classic NVP/SOAP API requests:

api.sandbox.paypal.com
api-3t.sandbox.paypal.com
api-aa.sandbox.paypal.com
api-aa-3t.sandbox.paypal.com

Production Endpoints - Ready after June 2018

The Production environment will only allow the use of the POST method for classic NVP/SOAP API requests:

api.paypal.com
api-aa.paypal.com
api-3t.paypal.com
api-aa-3t.paypal.com

FAQs

What is the difference between the GET and POST HTTP request methods?

GET is used to request data, while POST is used to submit data to a specified resource. From a security perspective, the key difference is that GET requests pass parameters in the URL and can be cached. This site has much more detail about the differences.

Why is the PayPal REST API not impacted?

The REST API uses the various HTTP request methods as part of the API design. The GET method is used to request details about an object. Because API credential information is passed as HTTP headers, the risk associated with the caching of GET requests is reduced.

What are the specific API operations affected by this change?

Express Checkout API Operations

AddressVerify
BAUpdate
BillOutstandingAmount
Callback
CreateBillingAgreement
CreateRecurringPaymentsProfile
DoAuthorization
DoCapture
DoExpressCheckoutPayment
DoReauthorization
DoReferenceTransaction
DoVoid
GetBalance
GetBillingAgreementCustomerDetails
GetExpressCheckoutDetails
GetPalDetails
GetRecurringPaymentsProfileDetails
GetTransactionDetails
ManageRecurringPaymentsProfileStatus
RefundTransaction
SetCustomerBillingAgreement
SetExpressCheckout
TransactionSearch
UpdateAuthorization
UpdateRecurringPaymentsProfile

Mass Payments API Operation

MassPay

Website Payments Pro API Operations

BillOutstandingAmount
CreateRecurringPaymentsProfile
DoCapture
DoDirectPayment
DoNonReferencedCredit
DoReauthorization
DoReferenceTransaction
DoVoid
GetBalance
GetRecurringPaymentsProfileDetails
GetTransactionDetails
ManagePendingTransactionStatus
ManageRecurringPaymentsProfileStatus
RefundTransaction
TransactionSearch
UpdateAuthorization
UpdateRecurringPaymentsProfile

Button Manager API Operations

BMButtonSearch
BMCreateButton
BMGetButtonDetails
BMGetInventory
BMManageButtonStatus
BMSetInventory
BMUpdateButton

UPDATE

PayPal is committed to providing the highest level of security to protect customer and transactional data, and we work closely with our merchant community to do the same. In response to feedback from several merchants, PayPal did not strictly enforce some of these vital security upgrades prior to the June 2017 deadline. However, in order to provide the most secure experience for all of our customers, PayPal must proceed with implementing these upgrades in the first half of 2018. In early 2018, we will conduct brief rounds of testing which will emulate the upgraded security experience so that merchants can understand the areas of their integration that still require work. Dates for these tests and full deployment will be published on this site at least two weeks prior to implementation.