question

I had tried to send an email to Payeezy support and did not receive a timely reply so called their support I was able to speak with a Payeezy support rep over the phone and who indicated that it would be possible to use Payeezy to retrieve a TransArmor multi-use Token and that token should be able to be used through a Clover device transaction. Then I received a response from the original email I'd send and that rep said it cannot be done. Ultimately I don't really care about which processor the transaction goes to and would be perfectly happy simply using the Clover Dev Pay API and glad to have it all "under one roof". However, a main goal of this effort is to take Card Account (PAN) Data completely out of scope. Payeezy accomplishes this by using a piece of client side javascript that communicates the PAN directly to Payeezy's server to retrieve a Transarmor Token. I suppose your dev pay could do the same, yet there does not appear to be a pre-built client side javascript app like Payeezy provides that handles the PAN data (keeping PAN out of scope of our network and servers)

Hi @PST,

It's not currently on our roadmap to buff up our Dev Pay API, but we are aware that it's a concern for our developers looking for a web payment solution. At this time do you mind explaining your need for web payments in detail? You may post a private comment if you prefer: https://community.clover.com/articles/10851/introd...

The information you provide will be a boost to our ability to advocate adding it to the roadmap.

Thanks,
Keith

Need for web payment is pretty straightforward. A billing page step in the purchase process where the end user client inputs their card information (PAN) and then a Next button takes them to a final verification page where they review the products and payments for the web purchase and then click a submit button which sends an Auth request to the merchant service provider (currently AuthorizeNet). If the Auth is successful then the order is persisted to the database. If the Auth is not successful then the end user can go back to the billing page and modify payment information.
So on the billing page would want the Next button to make an ajax call to your servers to send the PAN data directly to your API to retrieve a token. The response to the ajax call would be reviewed on the client side and if it was successful then the page, along with the tokenized PAN data would be submitted to my web server to get the final verification page and continue the purchase process. This is how the Payeezy.js would work. Payeezy provides the javascript "module" which handles the ajax call to get the token. So their takes the PAN data out of scope. I never actually touch the card data. It is input into a html textbox on the client and Payeezy's ajax call handles getting the token. I have to assume they have that solution certified.
https://developer.payeezy.com/select-your-integration-method

If I had to write my own client side code, then essentially I'd be touching the card data while I'm transporting it to your DevPay API. I'm not a PCI expert but mainly my goal is to never have PAN data exposed to my systems or my network, effectively eliminating the need to become a PCI expert and worry about compliance.
hope that all made sense.