Notice of non-liability:
PayPal, Inc. is providing the information in this document to you “AS-IS” with all faults. PayPal, Inc. makes no warranties of any kind (whether express,
implied or statutory) with respect to the information contained herein. PayPal, Inc. assumes no liability for damages (whether direct or indirect), caused
by errors or omissions, or resulting from the use of this document or the information contained in this document or resulting from the application or use
of the product or service described herein. PayPal, Inc. reserves the right to make changes to any information herein without further notice.
This document describes the HTTPS interface, which allows you to post transactions directly
to the Payflow servers. Use the HTTPS interface for all operating systems and language
besides Java and .NET.
Documentation Problems
If you discover any errors in or have any problems with this documentation, please email us by
following the instructions below. Describe the error or problem as completely as possible and
give us the document title, the date of the document, and the page number or page range.
To contact Developer Technical Support about documentation problems:
1. Log in to your account at
password in the Member Log In box
2. Click Help Center at the bottom of the box on the right side of the page.
3. Click Email PayPal Technical Support.
4. Complete the form.
Revision History
DateDescription
August 2007First version of this document.
https://developer.paypal.com/ by entering your email address and
HTTPS Interface Developer’s GuideAugust 20073
Revision History
4August 2007HTTPS Interface Developer’s Guide
1
This chapter contains the following topics:
z Overview
z Moving from the Payflow SDK to the HTTPS interface
z Getting sample code
z Contacting Support
Overview
The HTTPS interface allows you to post transactions directly to the Payflow servers.
N OTE: If you are programming in Java or .NET, you can simplify the implementation by using
About the HTTPS Interface
an SDK. The SDKs are based upon this HTTPS interface. The .NET SDK can be used
with classic ASP. For SDKs, see
This guide contains the information you will need to construct the HTTPS message. The body
of the transaction is in name-value pair (NVP) or XMLPay format. For details of the NVP
format, see Website Payments Pro Developer’s Guide. For details of XMLPay format, see Website Payments Pro – XMLPay Developer’s Guide.
Moving from the Payflow SDK to the HTTPS interface
The Payflow Pro SDK contains APIs that do the following:
1. Create a connection with the Payflow server
2. Submit the transaction
3. Destroy the transaction
When you move to the HTTPS interface, you will have to rewrite these portions of the code.
You will need to complete four steps:
1. Write code that creates an HTTPS connection with the Payflow server.
2. Write an HTTPS request to submit your transaction data.
3. Receive the HTTPS reponse and extract the parameters.
4. Add code for error handling, retry logic, and duplicate transaction handling.
HTTPS Interface Developer’s GuideAugust 20075
About the HTTPS Interface
Getting sample code
Getting sample code
For sample code, visit the Payflow Gateway forum in the PayPal Developer Community.
Contacting Support
For support, post your question or issue on the Payflow Gateway forum or go to
https://www.paypal.com/mts, select Contact Support, and create a ticket.
6August 2007HTTPS Interface Developer’s Guide
Reference
2
This chapter contains the following topics:
z URLs for sending messages
z Standard HTTPS headers
z Transaction message
z Common problems
URLs for sending messages
Use the following URLs for sending transactions to PayPal's Payflow servers:
z Production (Live): https://payflowpro.verisign.com/transaction
z Pilot (Test): https://pilot-payflowpro.verisign.com/transaction
N OTE: You must include /transaction as part of the URL; otherwise, you'll receive a result
code 1, User Authentication error. This requirement will be removed in the future.
HTTPS headers
Standard HTTPS headers
HTTPS HeaderDescriptionReq?
ConnectState of the connection. The server returns the value close to
Content-LengthSize of message body.Yes
Content-TypeProvide one of the following values:
No
close the connection after the response is sent.
Ye s
z text/namevalue: transaction request body is in NVP
format.
z text/xml: transaction request body is in XMLPay 2.0
format.
HostProvide one of the two host URLs:
z Production: payflowpro.verisign.com
z Pilot: pilot-payflowpro.verisign.com
HTTPS Interface Developer’s GuideAugust 20077
Ye s
Reference
HTTPS headers
PayPal protocol headers
Protocol HeaderDescriptionReq?
X-VPS-REQUEST-IDA unique identifier for each request, whether the request is a
single NVP transaction or an XMLPay 2.0 document with
multiple transactions.
This identifier is associated with all the transactions in a
particular request. You must provide the X-VPS-REQUEST-ID
value in the transaction request.
The Payflow server uses the X-VPS-REQUEST-ID to check for
duplicate transaction requests. When a transaction request is
received, the server checks to see if the X-VPS-REQUEST-ID has
been used before by this merchant.
z If the X-VPS-REQUEST-ID has been used before, the server
views it as a retry transaction, and the transaction is treated as
a duplicate. The response to the original transaction is
returned to the merchant, but a name-value pair of
DUPLICATE=1 is added to indicate that this transaction is a
duplicate.
If the merchant sends new transaction data with a previously
used X-VPS-REQUEST-ID, the server ignores the new data
and returns the response to the original transaction associated
with that X-VPS-REQUEST-ID.
z If the X-VPS-REQUEST-ID has not been used before, the
server stores the X-VPS-REQUEST-ID to ensure that the X-VPS-REQUEST-ID is not reused and then runs the associated
transactions.
Duplicate checking is designed for short-term retries (a few
minutes to a few hours after the original transaction).
Although the X-VPS-REQUEST-ID is stored for a minimum
of 30 days, it is not recommended that you send a retry so
long after the original transaction.
Data type: 1 to 32 printable characters
Ye s
X-VPS-CLIENTTIMEOUT
Time-out value in seconds. A transaction times out if the elapsed
time between ending the original transaction request and
Ye s
receiving the transaction response exceeds the value of X-VPS-CLIENT-TIMEOUT.
The recommended value is 45.
X-VPS-VITCLIENTCERTIFICATION-ID
A random globally unique identifier (GUID) that is currently
required. This requirement will be removed in the future. At this
time, you can send any alpha-numeric ID up to 32 characters in
Ye s
length.
N OTE: Once you have created this ID, do not change it. Use the
same ID for every transaction.
8August 2007HTTPS Interface Developer’s Guide
Integrator-provided headers
These headers are extensions to the Payflow HTTPS interface. The extension parameters
describe the version of the application and the application’s environment.
N OTE: Even though these parameters are not required, it is strongly recommended that you
send them.
ParameterDescriptionReq?
Reference
Transaction message
X-VPS-VITINTEGRATION-PRODUCT
X-VPS-VITINTEGRATION-VERSION
X-VPS-VIT-OS-NAMEName of operating system that the application is running
X-VPS-VIT-OSVERSION
Identifies the product that is integrated with the Payflow
server.
Data type: string
Examples: iPayment, ColdFusion, MIVA, shopping
cart
Default: blank
Version of the software as defined by the integrator or
vendor. Limited to the major version and one digit of the
minor version.
Data type: alphanumeric string in the format:
<Major Version>.<Minor Version>
Examples: 1.1, 4.5, 10.0, Linux2.1
Default: blank
on.
Data type: string
Examples: Linux, SunOS, Windows 2000, Windows NT, Windows XP, Mac OS X, Free BSD.
Default: blank
Version of operating system that application is running on.
Data type: string in the format XXX.X
Example: 2.4
Default: blank
No
No
No
No
X-VPS-VIT-RUNTIMEVERSION
Version of runtime environment of the language that the
application is running on.
Data type: string in the format XXX.X
Examples: 10.1, 2.5
Default: blank
No
Transaction message
The transaction message communicates the initial transaction data to the server. It is made up
of the transaction request and response.
HTTPS Interface Developer’s GuideAugust 20079
Reference
Transaction message
N OTE: The examples below are in NVP format. XMLPay uses the same format as NVP except
that the content-type is text/xml and the body of both the request and response
contain the XML document.
Transaction request
The transaction request consists of a transaction request header and body.
Transaction request header
The following is an example of a transaction request header associated with a message in NVP
format:
The transaction request body contains the transaction information. The following is an
example of a transaction request body in NVP format:
TRXTYPE[1]=S&ACCT[16]=5105105105105100&EXPDATE[4]=0109&
TENDER[1]=C&INVNUM[8]=INV12345&AMT[5]=25.12&PONUM[7]=PO12345&
STREET[23]=123 Main St.&ZIP[5]=12345&USER[6]=jsmith&
VENDOR[6]=jsmith&PARTNER[8]=PayPal&PWD[8]=testing1
The bracketed numbers are length tags that allow you to use the special characters & and = in
the value sent. See the Website Payments Pro Developer’s Guide for more information.
Transaction response
The transaction response consists of a transaction response header and body.
Transaction response header
The following is an example of a transaction response header associated with a message in
NVP format:
Connect: close
Server: VPS-3.033.00
X-VPS-REQUEST-ID: 9a5534f7e4f3a5e5138b062e000b279a
X-VPS-RESPONSE-ID:
V7sMZIeBBmrPMwNM7sZkPi3bLsaJ/QusF0LoEroT8/QD9d/AwUQbFYbKnhDOQ4HXRJ
Date: Mon, 16 May 2005 22:48:06 GMT
Content-Type: text/namevalue
Content-Length: 145
10August 2007HTTPS Interface Developer’s Guide
X-VPS-REQUEST-ID is the same ID sent in the transaction request.
N OTE: Ignore the X-VPS-RESPONSE-ID. It will be removed at a later time.
Transaction response body
The transaction response body contains the response to the request. The following is an
example response body in NVP format: