We've run into a few instances where it would be nice to be able to alter the TransactionRequest object before it is sent off on a request. Here are a couple of examples:
1. We use a name field for the billing name. Would be nice to be able to plug that set of values into the name fields on the TransactionRequest.
2. We hit the hard line item limit on a single transaction (30?). It would be nice to be able to implement a strategy to prevent these orders from erring out.
I see there are @todos about making this happen. So I'm hopeful that you all are open to the idea. I'm happy to submit a patch for the AcceptJS payment gateway. We don't use the Echeck or VisaCheckout so I feel less comfortable doing so for those. Thanks!
Issue fork commerce_authnet-3089783
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
lkacenjaHere is my first stab. I figured creating an event for the payment creation and refund operations might be a good way to go. Thanks.
Comment #3
gregglesJust updating status since there's a patch here.
Comment #4
lkacenjaI realized that you aren't able to change the customer information like firstName and lastName or phoneNumber when creating a transaction. So I added a second set of events that are fired off when you create or update a PaymentProfile. I've attached a patch. Thanks!
Comment #5
nathaniel commentedThanks for the patch! Needed this to update order description in the email from authnet.
(previously: x_description, default: Goods or Services)
Comment #6
zengenuity commentedRe-roll.
Edit - Bad patch on this one. Fixing it.
Comment #7
zengenuity commentedCorrected re-roll patch.
Comment #9
mglamanLooks great, to me. I'd like to reduce backward compatibility problems by not overriding the constructor and create methods.
nit: it's the CreateTransactionRequest resource, so let's name it create_transaction_request
See previous event name nit
It's not as common, but I'd like to use the "setter" pattern here to prevent a bunch of possible BC nightmare.
So we'd add setEventDispatcher. And in `create` we'd call parent::create and with that result setEventDispatcher on ourselves.
No more overridden constructor. No create method BC woes
Comment #10
mglamanNevermind me. Refunds and Voids are all under that resource.
Comment #12
rymcveighJust noting that I attempted to patch the latest release of this module with the latest commit on this branch and saw the same error tests are showing when attempting to checkout with test credentials.
The patch in #7 works great though.
Comment #13
lkacenjaRan into a merge conflict with the previous patch, when attempting to update the module. I think those are now resolved.
Comment #14
vmarchukNew patch compatible with version 8.x-1.7
Comment #15
nathaniel commentedSymfony Event class deprecated 9.1.0... (broke while testing on a Drupal 10 site).
https://www.drupal.org/node/3159012
Before:
use Symfony\Component\EventDispatcher\Event;After:
use Drupal\Component\EventDispatcher\Event;Comment #16
nathaniel commentedTried to update the local patch based on the merge request / feedback and updated EventDispatcher\Event.
Comment #17
gregglesThanks for your help vmarchuck and for that QA and update for Drupal 10, Nathaniel!
Nudging this to RTBC. We've been using the various versions of it since 2019. Would be great to get a maintainer's feedback.
Comment #19
jsacksick commentedMade several changes / fixes to the patch and committed it.
Comment #21
greggles@jsacksick do you have an interdiff of your changes?
Comment #22
gregglesAlso super appreciate you taking a look at this and committing it!
Comment #23
gregglesI think this is an interdiff of the changes from 16 up through #20.
Looks like some great improvements to me. Thanks!