ProtectPay PMI – Seamless Payment Interface

 
Considerations specific to the Seamless Payment Interface
As with all of the ProtectPay Payer Management Interfaces, the SPI is only needed when new payment method information must be collected. To process using an existing ProtectPay token, simply perform a ProtectPay API processing call.

The ProtectPay SPI is a solution that allows a merchant to "paint" the entire checkout experience to a cardholder’s browser, then with a "submit" button POST cardholder data to ProPay, rather than to the merchant’s own website.

Use of the ProtectPay SPI satisfies many of the validation requirements under PCI DSS, and merchants or partners who employ this solution are required to validate using SAQ A-EP.


SPI Processing Configurations
The SPI can be configured to perform various payment method storage and/or processing requests. These options include:
  • Create a Payment Method
  • Create and Authorize a Payment Method for a specified amount
  • Create and Process a Payment Method for a specified amount
  • Authorize a payment method for a specified amount
  • Process a payment method for a specified amount
  • Authorize a payment method for a specified amount and create a PaymentMethodId only if authorization is successful

Summary of Processing
  1. A Customer finishes shopping and clicks on a link to check out.
  2. Before the customer is able to see the checkout page, the merchant should make a call to the ProtectPay API to Get a Temp Token
  3. The merchant uses this data to encrypt all of the information that the merchant can know without any input from the cardholder
  4. The merchant then paints the checkout page. Include the following on that page:
    • The encrypted blob of data (hidden)
    • A reference ID to the temp token (hidden)
    • A submit button with special javascript code
  5. When the cardholder clicks submit, execute the special javascript code to:
    • Perform client-side validation of the card (16 digits, valid format, all data present on page, etc.)
    • POST data to the SPI rather than back to the merchant’s server
    • Disable the back button on the cardholder’s browser.
    • Display a ‘Transaction in Progress’ message, spinning wheel, or whatever suits the merchant’s fancy.
  6. The SPI follows instructions contained in the POST to process the transaction and potentially save a payment method for future transactions. (Note, the SPI does NOT do anything to the cardholder browser experience at this point. The browser remains on the checkout page)
  7. When the SPI has finished processing, it redirects the cardholder to the return URL it was given in the encrypted block of data. This redirect will contain an encrypted response that should be decrypted by the merchant’s system (See encryption process in this manual)
  8. The merchant displays a ‘success page’ or ‘failure page’ of his or her own design.

 
Get started: Create a temp token
 
Just take me to the API docs