Merchants frequently misunderstand or underestimate their obligations under the PCI Data Security Standard. Systems "fall under the scope" of the PCI DSS whenever they store, process, or transmit cardholder data, but merchants often believe that, so long as they don't actually store card numbers, they don't need to worry about PCI compliance. Such is not the case, and ProtectPay helps merchants deal with this reality by providing what are known as Payer Management Interfaces or PMIs. A PMI’s purpose is to provide for the collection of cardholder information into an interface hosted by ProPay rather than one which causes sensitive information to traverse the customer’s own web server. ProPay offers two different PMI options to its ProtectPay customers.
Hosted Payment Page
The first (and probably easier to integrate) option is called the Hosted Payment Page. The HPP is an interface, hosted on our servers, which you use an API call to configure. Some of the settings you can control:
- Whether or not our interface should collect a card’s the security code, the billing address, and other optional, but often collected data elements used for credit card processing.
- The look and feel of our page can be controlled by providing the URL of a .CSS file that you host on your own web server.
- Whether or not our interface should allow the user to select the MasterPass wallet solution.
Click to learn about processing with the HPP
Seamless Payment Interface
The SPI can be a challenge to integrate but it gives you the most control over a visitor to your website’s checkout experience. The SPI is built around the concept of you serving up an interface to the cardholder into which he or she enters their payment info. Using JavaScript, or some other client-side code that is embedded into a submit button, you cause the page to POST data to us instead of to you. Upon receipt of that info, we will “do our thing” then redirect the cardholder’s browser back to your website along with a payload that tells you whether or not a transaction was successfully processed. Click to learn about processing with the SPI
Skipping the PMI (not recommended but possible)
Some ProtectPay users want to directly tokenize card numbers using an API. This is not typically recommended, as going this route doesn’t offer the full benefit of ProtectPay. Merchants systems’ remain "in scope" whenever they touch cardholder data, so skipping a PMI integration is usually a bad idea. Using ProtectPay without a PMI at least confers the benefits of tokenization onto the storage of payment data used for future transactions. If you want to explore directly tokenizing cardholder data into Protectpay, click to tokenize with the API
ProtectPay – Processing with an Existing Token
Save the ProtectPay tokens you get back from a ProtectPay PMI because once you have a token, you can process with it again and again. (Don’t use a PMI for recurring transactions.) By the way, a ProtectPay token can represent more than just a credit card number. A bank account, for eCheck processing; or a ProPay account number, for Spendback, can also be tokenized. Sale , Authorize , and Capture are all supported by ProtectPay. You can, of course, also manage your existing payment methods with both a [delete] and [edit] API method, but neither of those are documented on this website. Please refer to our API documentation to perform these actions.
ProtectPay – Voids and Refunds
You don’t actually need to use ProtectPay to initiate voids and refunds because neither of those two actions needs you to provide a card number. Voids and refunds ask for a transaction identifier. That said, ProtectPay supports these methods via API…because you still need to do them. Click to learn more about Voids and Refunds |