Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Credit card processing integration #126

Open
scaspers opened this issue Aug 7, 2018 · 2 comments
Open

Credit card processing integration #126

scaspers opened this issue Aug 7, 2018 · 2 comments
Assignees
Labels
Feature Nice To Have Desired for shipping with a version, but may get negotiated out to a future version

Comments

@scaspers
Copy link
Collaborator

scaspers commented Aug 7, 2018

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.

@scaspers scaspers added this to the v2.0 milestone Aug 7, 2018
@scaspers scaspers added Feature Nice To Have Desired for shipping with a version, but may get negotiated out to a future version labels Aug 7, 2018
@DanielCaspers
Copy link
Owner

DanielCaspers commented Aug 26, 2018

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
Copy link
Owner

@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

@DanielCaspers DanielCaspers removed this from the v2.0 milestone Apr 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Nice To Have Desired for shipping with a version, but may get negotiated out to a future version
Projects
None yet
Development

No branches or pull requests

2 participants