Authnet: accept.js support #3224

dingels35 · 2019-05-16T13:53:15Z

Authorize.net provides a way to capture credit cards without credit card data (number, expiration, etc) ever passing through the merchant's server. Using their accept.js client library, CC info is submitted directly to their server, which responds with a payment nonce. This nonce can then be sent safely though the merchant's server and used in authorize and purchase transactions. Full documentation here: https://developer.authorize.net/api/reference/features/acceptjs.html

This PR adds an OpaqueDataPaymentToken to handle authnet's payment nonce.

Given the following output from the API called made by the accept.js library:

{
  "opaqueData": {
    "dataDescriptor": "COMMON.ACCEPT.INAPP.PAYMENT",
    "dataValue": "eyJj...MSJ9"
  },
  "messages": {
    "resultCode": "Ok",
    "message": [{"code": "I00001", "text": "Successful."}]
  }
}

Authorization can be submitted like this:

token = OpaqueDataPaymentToken.new('eyJj...MSJ9', data_descriptor: 'COMMON.ACCEPT.INAPP.PAYMENT')
gateway = AuthorizeNetGateway.new(login: '', password: '')
gateway.authorize(123, token, order_id: 1)

Resolves #3187

% ruby -I test test/remote/gateways/remote_authorize_net_test.rb                           
Loaded suite test/remote/gateways/remote_authorize_net_test
Started
.....................................................................
Finished in 54.372302 seconds.
------------------------------------------------------------------------------------------------------------------------
69 tests, 238 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
------------------------------------------------------------------------------------------------------------------------
1.27 tests/s, 4.38 assertions/s

% ruby -I test test/remote/gateways/remote_authorize_net_opaque_data_test.rb 
Loaded suite test/remote/gateways/remote_authorize_net_opaque_data_test
Started
.....
Finished in 6.58923 seconds.
------------------------------------------------------------------------------------------------------------------------
5 tests, 19 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
------------------------------------------------------------------------------------------------------------------------
0.76 tests/s, 2.88 assertions/s

Loaded suite test/unit/gateways/authorize_net_test
Started
.................................................................................................
Finished in 0.251408 seconds.
------------------------------------------------------------------------------------------------------------------------
97 tests, 575 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
------------------------------------------------------------------------------------------------------------------------
385.83 tests/s, 2287.12 assertions/s

therufs

Thanks for the PR -- it looks pretty good to me :D Hoping to get at least one more set of eyes on it for feedback.

lib/active_merchant/billing/opaque_data_payment_token.rb

curiousepic · 2019-05-30T14:10:24Z

Hi @dingels35, still looking at this, but my first thought is whether the OpaqueDataPaymentToken the best name/abstraction. The name is a bit general; is the class also general enough to be used for similar implementations, or are there specifics that tie it to Authnet Accept.js's notion of a payment token?

dingels35 · 2019-05-30T14:28:00Z

@curiousepic - Good question. I definitely wanted this to be generic enough to handle other (possibly future) payment types.
There is an existing ApplePayPaymentToken that generates the exact same xml - <opaqueData><dataDescriptor>...</dataDescriptor><dataValue>...</dataValue></opaqueData>. I considered creating an OpaqueDataPaymentToken as a base for both an ApplePayPaymentToken and an AcceptJsPaymentToken, but I didn't really want to mess with existing apple pay functionality.

The way I have things set now, this could be used for apple pay scenarios. It can also be used for Visa Checkout and Android Pay (documentation links below). So I think having just one OpaqueData type that can be used for all 4 scenarios (accept.js, apple, android, visapay) is a good way to build support for multiple current, and possible future, authorize.net payment options.

https://developer.authorize.net/api/reference/index.html#visa-checkout
https://developer.authorize.net/api/reference/index.html#mobile-in-app-transactions-create-an-android-pay-transaction

curiousepic · 2019-05-30T18:30:08Z

@dingels35 I was actually thinking more about applications beyond Authnet, rather than other Authnet token types. If it's tied to Authnet, let's maybe make that explicit in the name.

dingels35 · 2019-05-31T02:23:58Z

@curiousepic - I like your thoughts. We could definitely add token classes for other payment types - AndroidPayPaymentToken, VisaCheckoutPaymentToken, and AcceptJsPaymentToken. Doing this would mostly require that each merchant consider each class separately.

Another option would be to allow the existing PaymentToken act on its own. I think I could use the same code listed in my PR summary to use a PaymentToken instead of an OpaqueDataPaymentToken. I'd likely just need to modify the PaymentToken class to something like this:

class PaymentToken
  attr_reader :payment_data, :metadata
  def initialize(payment_data, options = {})
    @payment_data = payment_data
    @metadata = options.with_indifferent_access
  end
  def type
    'payment_token'
  end
end

Exposing metadata would allow me to pull out the data_descriptor in gateways/authorize_net.rb. And I could also validate in that class that token.metadata[:data_descriptor] exists.

Thoughts on this approach? If you're not keen on it, I can also just rename that class to AuthorizeNetPaymentToken and keep this scoped to authnet only.

curiousepic · 2019-06-04T17:06:01Z

@dingels35 Hi Cory, these are some interesting approaches. I think we should probably keep things slim here since we're approaching scope bloat, but I'd like to get some more perspectives for how to proceed from my colleagues and get back to you. @activemerchant/shopify-payments-devs may be interested as well.

bayprogrammer

Things look very nice with the code and tests. I especially like the remote tests and the special gateway class to simulate the necessary front-end flow. Well done!

With respect to modeling the specialized token needed to support the Accept.js token type, I believe we'd be better off scoping these changes to only within the Authorize.net-relevant code, rather than expanding any top-level payment classes. We should be especially cautious with modifying the PaymentToken class directly right now.

There is precedence for the use of a nested gateway-specific token class within the StripeGateway class: StripeGateway::StripePaymentToken. Could we do something similar for the opaque data required by AuthorizeNetGateway? Perhaps AuthorizeNetGateway::OpaqueDataToken? Then we can move forward with minimal risk to existing code. We can always lift the class up to the top-level if and when we discover that this specific format of opaque data might be applicable to other gateways.

If that would work, the modifications to update the tests should be minimal, and it will be easier for us to reason about how it will interact with our own existing code when we go to integrate this patch into our internal systems.

curiousepic · 2019-06-04T19:06:39Z

@bayprogrammer Nice, I like that path as well.

taf2 · 2019-06-26T16:19:25Z

what was wrong with #2422 ?

bayprogrammer · 2019-06-26T20:56:31Z

what was wrong with #2422 ?

@taf2 I'm not aware that anything was necessarily wrong with it, but I'm guessing it simply didn't get picked up on our radar at the time. We've been making a renewed push at becoming more proactive in responding to issues and PRs.

@dingels35 How are things going on your side? Were my recommended changes something you can do?

dingels35 · 2019-06-27T16:13:57Z

@bayprogrammer - Thanks for checking back in. Your comments are good - I like that approach. I had some time off earlier in June and am heading out for a long weekend again. But I'll get this updated for you to look at in the next 2 weeks.

bayprogrammer · 2019-06-27T16:18:23Z

@dingels35 Awesome, thanks so much. Have a great long weekend! 😄

…PaymentToken

dfltr · 2019-10-01T00:21:12Z

Hi all 👋 Would love to get this merged so we can all drop our Accept.js monkeypatches. Any updates on it?

bayprogrammer · 2019-10-25T12:36:09Z

@dingels35 @dfltr I apologize I didn't see that this PR had been updated since I last looked at it. It's back on my radar and I will try to re-review and hopefully we can get this one merged in!

paulsingh · 2020-07-29T20:22:33Z

Hey guys, checking back in on this one: I'd love to use Accept.js via ActiveMerchant! :)

taf2 · 2020-07-29T20:42:33Z

My patch still works...

ChrisNelsonBHG · 2022-09-27T16:48:37Z

@bayprogrammer or @curiousepic 👋 I'm on @dingels35 's team, revisiting this issue. We'd love to drop our fork of ActiveMerchant if we can get this (or #4406) across the line.

Last we saw I think we were waiting on comments from @bayprogrammer. Is it realistic to revive this PR at this point, or how can we proceed?

bayprogrammer · 2022-10-05T13:04:36Z

@ChrisNelsonBHG apologies, I am afraid I wasn't able to get back to this while I was still at Spreedly. I no longer work for Spreedly and I no longer have commit access to this project (nor would I remember enough about this accept.js business to be of much help any longer 😅).

curiousepic · 2023-10-25T17:17:54Z

Marking this "of interest" before a cleanup of stale PRs

Waylon87 · 2024-04-01T21:06:03Z

same: Marking this "of interest" before a cleanup of stale PRs

taf2 · 2024-04-01T21:16:45Z

Pretty sure we forked active_merchant long ago for this specific feature in authnet - seems pretty important feature...

dingels35 mentioned this pull request May 16, 2019

Authnet: Parse card_type from response #3218

Closed

dingels35 force-pushed the authnet-accept-js branch 2 times, most recently from 629ba3d to 495368b Compare May 16, 2019 14:29

dingels35 mentioned this pull request May 17, 2019

Question: Is accept.js supported? #3187

Open

therufs suggested changes May 30, 2019

View reviewed changes

lib/active_merchant/billing/opaque_data_payment_token.rb Outdated Show resolved Hide resolved

dingels35 added 2 commits May 30, 2019 10:05

parse card_type from authorize.net response

55977ad

add opaque data token type so accept.js payments can be accepted

66b0ac4

dingels35 force-pushed the authnet-accept-js branch from 495368b to 66b0ac4 Compare May 30, 2019 15:09

bayprogrammer reviewed Jun 4, 2019

View reviewed changes

refactor: Billing::OpaqueDataPaymentToken -> Gateways::AuthorizeNet::…

1785c32

…PaymentToken

clintmiller mentioned this pull request Apr 25, 2022

Authorize.Net: Support Accept.js PCI Tokens #4406

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Authnet: accept.js support #3224

Authnet: accept.js support #3224

dingels35 commented May 16, 2019

therufs left a comment

curiousepic commented May 30, 2019 •

edited

Loading

dingels35 commented May 30, 2019

curiousepic commented May 30, 2019 •

edited

Loading

dingels35 commented May 31, 2019

curiousepic commented Jun 4, 2019

bayprogrammer left a comment

curiousepic commented Jun 4, 2019

taf2 commented Jun 26, 2019

bayprogrammer commented Jun 26, 2019

dingels35 commented Jun 27, 2019

bayprogrammer commented Jun 27, 2019

dfltr commented Oct 1, 2019

bayprogrammer commented Oct 25, 2019

paulsingh commented Jul 29, 2020

taf2 commented Jul 29, 2020

ChrisNelsonBHG commented Sep 27, 2022

bayprogrammer commented Oct 5, 2022

curiousepic commented Oct 25, 2023

Waylon87 commented Apr 1, 2024

taf2 commented Apr 1, 2024

Authnet: accept.js support #3224

Are you sure you want to change the base?

Authnet: accept.js support #3224

Conversation

dingels35 commented May 16, 2019

therufs left a comment

Choose a reason for hiding this comment

curiousepic commented May 30, 2019 • edited Loading

dingels35 commented May 30, 2019

curiousepic commented May 30, 2019 • edited Loading

dingels35 commented May 31, 2019

curiousepic commented Jun 4, 2019

bayprogrammer left a comment

Choose a reason for hiding this comment

curiousepic commented Jun 4, 2019

taf2 commented Jun 26, 2019

bayprogrammer commented Jun 26, 2019

dingels35 commented Jun 27, 2019

bayprogrammer commented Jun 27, 2019

dfltr commented Oct 1, 2019

bayprogrammer commented Oct 25, 2019

paulsingh commented Jul 29, 2020

taf2 commented Jul 29, 2020

ChrisNelsonBHG commented Sep 27, 2022

bayprogrammer commented Oct 5, 2022

curiousepic commented Oct 25, 2023

Waylon87 commented Apr 1, 2024

taf2 commented Apr 1, 2024

curiousepic commented May 30, 2019 •

edited

Loading

curiousepic commented May 30, 2019 •

edited

Loading