PayPal SOAP API Basics

The PayPal SOAP API is based on open standards known collectively as web services, which include the Simple Object Access Protocol (SOAP), Web Services Definition Language (WSDL), and the XML Schema Definition language (XSD). A wide range of development tools on a variety of platforms support web services.

Like many web services, PayPal SOAP is a combination of client-side and server-side schemas, hardware and software servers, and core services.

Figure 1. PayPal SOAP High-level Diagram

In an object-oriented processing model, the interface to SOAP requests/responses is an object in your application's native programming language. Your third-party SOAP client generates business-object interfaces and network stubs from PayPal-provided WSDL and XSD files that specify the PayPal SOAP message structure, its contents, and the PayPal API service bindings. A business application works with data in the form of object properties to send and receive data by calling object methods. The SOAP client handles the details of building the SOAP request, sending it to the PayPal service, and converting the response back to an object.

PayPal WSDL/XSD Schema Definitions

The PayPal Web Services schema and its underlying eBay Business Language (eBL) base and core components are required for developing applications with the PayPal Web Services API. The following are the locations of the WSDL and XSD files.

Table 1. Location of PayPal WSDL and XSD Files
Development and Test with the PayPal Sandbox API Service
PayPal Schema
eBL Base Components and Component Types
Production with Live PayPal Web Services API Service
PayPal Schema
eBL Base Components and Component Types

PayPal SOAP API Definitions

The PayPal SOAP API comprises individual API definitions for specific business functions. As a foundation, the API relies on eBay Business Language (eBL) base and core components. The core eBL structures AbstractRequestType and AbstractResponseType are the basis of the SOAP request and response of each PayPal API. AbstractResponseType is also the framework for error messages common across all PayPal APIs.

PayPal has made some schema design decisions that can affect how businesses design their own applications.

  • Enumerations: Enumerations are defined directly in the PayPal API schema.
  • Troubleshooting information: The PayPal API returns information about elements that trigger errors.
  • Backward compatibility: The PayPal API is versioned so that business applications are backward compatible when new elements are introduced to the server-side schema.
Note: eBL defines many structures that are specific to processing auctions. PayPal's SOAP schema includes these definitions to maintain compatibility with eBay's SOAP and for possible future joint use of SOAP across both eBay and PayPal. The material focuses only on those SOAP definitions pertinent to use of the PayPal SOAP API.


The PayPal SOAP API service is protected to ensure that only authorized PayPal members use it. There are four levels of security:

  1. A required API username (Username field) and API password (Password field).
  2. A third required authentication mechanism, which is either one of the following:
    • Client-side request signing using a PayPal-issued API Certificate
    • Request authentication using an API Signature included in the request (Signature field)
  3. An optional third-party authorization to make the API call on some other account's behalf (the optional Subject field).
  4. Secure Sockets Layer (SSL) data transport.

A failure of authenticated security at any one of these levels denies access to the PayPal SOAP API service.

SOAP RequesterCredentials: Username, Password, Signature, and Subject

For the security of your business, PayPal must verify that merchants or third-party developers are permitted to initiate a transaction before they make one. PayPal authenticates each request. If the request cannot be authenticated, a SOAP security fault is returned.

In the SOAP request header, your SOAP client must set the Username, Password elements to pass an API username/password combination. In addition, you can set the Signature or Subject elements to specify your API signature string and an optional third-party account email address for authentication.

The following example shows part of the RequesterCredentials elements.

These elements are required for all SOAP requests.

<RequesterCredentials xmlns="urn:ebay:api:PayPalAPI" xsi:type="ebl:CustomSecurityHeaderType">
<Credentials xmlns="urn:ebay:apis:eBLBaseComponents" xsi:type="ebl:UserIdPasswordType">
Table 2. RequesterCredentials Authentication Elements in SOAP Header
Element Value Description
<Username> api_username Your API username, which is auto-generated by PayPal when you apply for a digital certificate to use the PayPal SOAP API. You can see this value on in your Profile under API Access > API Certificate Information.
<Password> api_password Your API password, which you specify when you apply for a digital certificate to use the PayPal SOAP API.
<Signature> api_signature Your API signature, if you use one instead of an API Certificate.
<Subject> authorizing_ account_ emailaddress The email address of a third-party for whom you are sending requests to the PayPal SOAP API. Your API username must have been granted permission by this third-party to make any particular PayPal API request.

SOAP Service Endpoints

Depending on your chosen authentication mechanism, your SOAP requests must be processed by different service endpoints.

Table 3. SOAP Service Endpoints
Authentication Mechanism Live Production Endpoint Test (Sandbox) Endpoint
API Signature
API Certificate

SOAP Request Envelope

The following diagram illustrates the contents of a PayPal SOAP request envelope.

All PayPal APIs are based on two core structures: AbstractRequestType and AbstractResponseType.

Figure 2. Diagram of SOAP Request Envelope

Request Structure

The following annotated description of the SOAP request structure shows the elements required by the PayPal SOAP API.

General Structure of PayPal API SOAP Request

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:xsi= ""
<RequesterCredentials xmlns="urn:ebay:api:PayPalAPI">
<Credentials xmlns="urn:ebay:apis:eBLBaseComponents">
<specific_api_name_Req xmlns="urn:ebay:api:PayPalAPI">
<Version xmlns=urn:ebay:apis:eBLBaseComponents">service_version
<required_or_optional_fields xsi:type="some_type_here">				data
Table 4. Annotation of Generic SOAP Request
Lines Comment
12, 13 The <Username> and <Password> fields are part of the PayPal SOAP API <RequesterCredentials> security authentication mechanism you must construct for every SOAP request header.
14 The <Signature> element should include your API signature string if that is the kind of API credential you are using.
15 The <Subject> element can specify a third-party PayPal account by whom you are authorized to make this request.
19 through 27 The SOAP request for every PayPal API follows this element-naming pattern. The API's specific name is appended with Req, and in this element the specific_api_name_Request is nested. Each specific_api_name_Request has a corresponding specific_api_name_RequestType.
22 The number of the PayPal SOAP API version is required on each SOAP request. This version number is the value of ns:version in
24 For details about required and optional elements and values for specific requests, see the description of individual APIs.

SOAP Message Style: doc-literal

PayPal uses doc-literal SOAP messaging, not rpc-encoding. With doc-literal, a single service interface call passes an XML document in the request to the PayPal API server, which responds with an XML document instance.

Response Structure

The following is an annotated description of the structure of a SOAP response from the PayPal API where response is Success:

<?xml version="1.0"?>
xmlns:SOAP-ENV= ""
<RequesterCredentials xmlns="urn:ebay:api:PayPalAPI"
<SOAP-ENV:Body id="_0">
<specific_api_name_Response xmlns="urn:ebay:api:PayPalAPI">
<Timestamp xmlns="urn:ebay:api:PayPalAPI">  				dateTime_in_UTC/GMT
<Ack xmlns="urn:ebay:apis:eBLBaseComponents">Success</Ack>
<Version xmlns="urn:ebay:apis:eBLBaseComponents">
<CorrelationId xmlns="urn:ebay:apis:eBLBaseComponents">
<Build xmlns="urn:ebay:apis:eBLBaseComponents">
<elements_for_specific_api_response>	  				data
Table 5. Annotation of Generic SOAP Response
Lines Comment
22 and 31 The specific_api_name_Response start and end elements.
23 Each API response contains a timestamp with its date and time in UTC/GMT.
24 The <Ack> element contains the string Success after the corresponding request has been successfully processed. In the case of errors, Ack is set to a value other than Success, and the response body contains an <Errors> element with information to help you troubleshoot the cause of the error. See Error Responses.
26 The <CorrelationID> element contains information about the PayPal application that processed the request. Use the value of this element if you need to troubleshoot a problem with one of your requests.
27 through 30 The different PayPal APIs return different structures depending on their response definitions. For detailed information, see the description of the individual APIs.
Note: Because a field is defined in the formal structure of an API response, this does not mean that the field is necessarily returned. Data are returned in a response only if PayPal has recorded data that corresponds to the field.

Error Responses

If a request is malformed or contains some other error, the body of the SOAP response contains an <Errors> element with other elements that can help you troubleshoot the cause of the error.

The structure of error messages are as follows:

The most important of these additional elements are as follows:

  • ShortMessage
  • LongMessage
  • ErrorCode

Additional information can appear as part of ErrorParametersType. For example, if the error in ParamID is ProcessorResponse, the Value would contain the processor-specific error, such as 0091. Values set in the ErrorParametersType are not set by PayPal; rather, they are passed through from the source.

Note: PayPal only passes selected values in ErrorParametersType.

The following example shows the error response if your API username and password do not match a legitimate API username and password on file with PayPal.

Example of SOAP Error Response: Bad Username or Password

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV: Envelope details  not  shown >
<S OAP-ENV:Header>... details not shown.</SOAP-ENV:Header>
<SOAP-ENV:Body id="_0">
<GetTransactionDetailsResponse xmlns="urn:ebay:api:PayPalAPI">
<Timestamp xmlns="urn:ebay:apis:eBLBaseComponents">
<Ack xmlns="urn:ebay:apis:eBLBaseComponents">	Failure</Ack>
<ShortMessage xsi:type="xs:string">
Authentication/Authorization Failed
<LongMessage xsi:type="xs:string">
Username/Password is incorrect
<ErrorCode xsi:type="xs:token">10002</ErrorCode>
<SeverityCode xmlns="urn:ebay:apis:eBLBaseComponents">
Error  				</SeverityCode>
<CorrelationID xmlns="urn:ebay:apis:eBLBaseComponents">
<Version xmlns="urn:ebay:apis:eBLBaseComponents">
<Build xmlns="urn:ebay:apis:eBLBaseComponents">1.0006</Build>		..  		other elements in response.

CorrelationID for Reporting Problems to PayPal

The value returned in CorrelationID is important for PayPal to determine the precise cause of any error you might encounter. If you have to troubleshoot a problem with your requests, we suggest that you capture the value of CorrelationID so you can report it to PayPal.

UTF-8 Character Encoding

The PayPal API assumes that all data in requests is in Unicode, specifically, the Unicode (or UCS) Transformation Format, 8-bit encoding form (UTF-8).

In responses, the API always returns data in UTF-8.

Date/Time Formats

The PayPal SOAP API schema defines date/time values as Coordinated Universal Time (UTC/GMT), using ISO 8601 format, and of type ns:dateTime.

An example date/time stamp is 2006-08-24T05:38:48Z

Core Currency Amount Data Type

The core currency amount data type is called BasicAmountType and is derived from string. All currency amount fields have the following structure:

  1. The currencyID attribute is required.
  2. The amount must have two decimal places.
  3. The decimal separator must be a period (".").
  4. You must not use any thousands separator.
  5. BasicAmountType has a data type of ebl:CurrencyCodeType, which defines a large number of different currency codes. However, for your processing to succeed, you must set currencyCode to a valid currency code. Some APIs support only a subset of currencies.

Here is an example. (The field name Amount is an example; actual field names can vary depending on the specific API.)

<Amount currencyID="currencyCode">3.00</Amount>