Credit card processing integration

[scaspers]

Links to possible providers integration methods.

Top contenders
PaymentDepot - Authorize.net and others (list saved in email)
Clearent - Multiple options
ABM(FirstData) - Multiple options

These two are not as desirable for reason not relating to API/SDK
Cayan - Multiple options
Dharma - MXMerchant
Dharma can also work with other 3rd party services such as Authorize.Net but with additional charges.

[DanielCaspers]

Provider recommendations

Authorize.NET. Enjoy both Accept.JS approach or the Accept Hosted with callback url approach.

At this moment, both seem like similar effort. This gives us the most flexibility of approaches, and isolates us from any one approach being removes.

Clearant - API looks very simple, Modal option is functional but not ideal.

The "Sale Transaction" with a single authorize + post looks really simple too.

The modal implementation has dependencies on Bootstrap, is difficult to provide data to like first-name, last-name etc to prefill known fields, and ultimately will feel like a separate page experience while having all the headaches of being hosted on our own site.

(ABM/FirstData/CardConnect) - IFrame only for the credit card field only, Would not recommend.

Do-able but not exciting. Not a portable solution unless we switch to another provider with IFrame for CC field only, which this is the first example we saw of this. They have no other options to switch to if the IFrame is declared a security risk, thereby obsoleting our provider from the digital experience side.

Guiding principals

1. If we own the form...
   1.1 We can guarantee we can prefill information
   1.2 We can control the user experience much better
   1.3 We can then HTTP POST it to someone else's API from the client, thereby remaining PCI compliant while having the most possible implementation flexibility
2. Emailing a receipt to a customer can have significantly varied difficulty depending on provider. It may require @scaspers to take on development effort to provide from PIC after the transaction has closed from point of sale side.
3. So long as we keep to either the API approach or the hosted + callback URL approach, changing to a vendor with the same implementation option should require minimal effort. This also means that if we switch to a differing approach, we should expect "throw away" in both design time and the code.
4. IFrames are violating SOLID principles
   4.1. Much more difficult to substitute functionality later unless another provider happens to fulfill the same "black-box" logic
   4.2. IFrames could become shunned by the broader community as a security vulnerability, and become broadly deprecated.
   4.3. The IFrames break the single responsibility principle by entangling UI concerns for credit card information with the secure processing aspect that we are interested in.

[DanielCaspers]

@scaspers will create a payment micro-app with the vendor of his choice. Since the usage is intended to be internal, user experience is a secondary concern to capturing the transaction.

The micro-app will implement some form of a callback URL pattern after showing the transaction receipt so that the user can continue what they were doing.

I will advise on the API and participate in design review.s