What are XML and PayPal's XMLPay?

About XML
XML (eXtensible Markup Language) is derived from Standardized General Markup Language (SGML) and HyperText Markup Language (HTML). In a sense, XML is a streamlined version of SGML, but its main advantage is that it lets you meaningfully annotate the text. XML maintains both SGML’s strength and HTML’s simplicity. Also, you can convert XML to HTML.

XML Benefits
These are the main benefits of XML:
  • Allows text annotation.
  • Presents text, data, and content to applications as a structured document.
  • Facilitates integration of diverse applications.
  • Supports digital signatures, allowing users to trust documents from unknown sources.
  • Easily produces large documents such as transaction logs and reports.
  • Is easy to produce, read, parse, and validate, and search for content.
Using XMLPay
PayPal's XMLPay product defines an XML syntax for payment transaction requests and responses in a payment processing network. The typical XMLPay user is an Internet merchant or merchant aggregator who wants to send credit cards, corporate purchase cards, Automated Clearing House (ACH), or other payment requests to a financial processing network. Using XMLPay's data type definitions, a user creates a client payment request and sends it—using a mechanism left unspecified by XMLPay—to an XMLPay-compliant server component. Responses (also formatted in XML) convey the results of the payment requests to the client.

Note: For specific examples of how to submit XML documents using the Payflow Pro client API, see the Payflow XMLPay Developer’s Guide or GitHub
XMLPay instruments
XMLPay supports payment processing using the following payment instruments:
  • Retail credit and debit cards
  • Corporate purchase cards: levels 1, 2, and 3
  • Automated Clearing House (ACH).
In a B2C Sale transaction, the buyer presents a payment instrument (for example, a credit card number) to a seller to transfer money. The seller uses XMLPay to forward the buyer’s payment information to a payment processor. The seller formats an XMLPayRequest and submits it either directly to an XMLPay-compliant payment processor or indirectly via an XMLPay-compliant payment gateway. Responses have the type XMLPayResponse.

The use of XMLPay doesn't affect buyer-to-seller and payment gateway-to-processor channels. For example, XMLPay typically isn't used in direct buyer-seller communications. Instead, conventional HTML form submission or other Internet communication methods are typically used. Similarly, because payment processors often specify different formats for payment requests, XMLPay server logic is usually localized at the payment gateway, leaving the legacy connections between gateways and processors unchanged.
The seller doesn't typically initiate XMLPay requests used in support of B2B transactions. Instead, an aggregator or trading exchange uses XMLPay to pass business-focused purchasing information (such as level 3 corporate purchase card data) to a payment gateway. The trading exchange links payment execution to other XML-based communications between buyers and sellers, such as advance shipping notice delivery, purchase order communication, or other B2B communication functions.
XMLPay messaging
The highest-level XMLPay structures represent payment transaction requests and responses.
Payment transactions are submitted, one or more at a time, as XMLPayRequest documents.
  • Merchant ID identifies the merchant of record for the transaction in the target payment processing network. The merchant of record may be different from the submitting party in a delegated processing model.
  • Transactions is the list of payment transactions to be processed. XMLPay supports up to 32 transactions per XMLPay document submission.
  • RequestAuth is an optional structure used to authenticate the submitting party when there's no transport-level authentication.
Each XMLPayRequest submission produces a corresponding XMLPayResponse document containing results for each submitted transaction request.

See also:
XMLPay Developer's Guide