🇮🇳India @vipin.j

Done.

This patch provides a Commerce Authnet payment gateway plugin from Authorize.net "Accept Hosted" payment gateway. The plugin is implemented with the documentation Accept Hosted. it provides all the necessary configurations required for both Authorize.net API and Commerce Payment gateway support.

Since this is the basic implementation with necessary requirements/services to be fulfilled like Performing a credit card transaction, Placing a full/partial refund request from the order UI, Maintaining Authorize.net Customer ID with Drupal user as Remote ID so the transactions, Payment methods, Shipping profiles history can be maintained over Authorize.net servers with CIM (Customer Information Management) support.

It does required implementation support for authOnlyTransaction transaction type, and also having possibilities of improvements.

vipin.j → created an issue.

The documentation provided by Authorize.net for Accept.js implementation prefers & recommend to perform a createTransactionRequest with the one-time-use token, or payment nonce received in exchange of payment data submitted.

We have referred a sample code for Drupal to implement Accept.js with createTransactionRequest, from the Sample Application on GitHub provided by Authorize.net and, experienced that when we build a transaction request with createTransactionRequest from the payment nonce received, we had no error/failure with the transaction, even when the Card Code(CVV) field was set to required or not with the Authorize.net merchant account. in both cases our transaction request executed successfully.

But when we preferred to create Customer Profiles first over transaction request i.e. Customer Profile and Payment profile to charge the customer credit card, which Commerce Authnet's Accept.js plugin doing currently, we face the error message as "Card Code Required", when we set the Card Code field to required with Authorize.net merchant account's "Payment Form - Fields" settings.

We can achieve security of the payment transaction while setting up the "Card Code" field to required, when we update the Accept.js plugin to perform a createTransactionRequest first over the creation of Customer Profile and Payment Profile.

Though we can fetch Customer ID and Payment Profile ID from the transId reference with a new request createCustomerProfileFromTransactionRequest and this transId returned as a response of createTransactionRequest.

But we need to accept that, whether we create profiles from Payment Nonce received or from the transId, The transaction request with reference to Profiles will always end-up with "Card Code is required." when Card Code field is set to required.

Re-rolling the patch #4 as it started failing after the recent release 1.2.0.

From patch #6 we are carrying a deprecated statement which has fixed with the issue #3336658 📌 PHP 8.2: ${var} in strings is deprecated Fixed

Re-rolling patch #24 to fix this issue in the patch.

Choosing approach #1 for this validation. The class method \Drupal\commerce\Plugin\Derivative\InboxLocalAction::getDerivativeDefinitions() is validated same as commerce_toolbar() against the setting commerce_dashboard_show_toolbar_link.

The attachment field cardinality is set to unlimited now.

Patch #3 started failing on recent release 8.x-1.3

The patch rerolled.

#14 and #15 patches were badly edited for test case requirement for plugin "Flat Rate + Per Item" which cause testbot failure.
here is the updated patch with a separate test case for "Flat Rate + Per Item".

@sdsc, I'm not the maintainer of Commerce Shipping but just a Drupal community contributor. including the patch in releases is totally in module maintainer's choice.

Yeah, but you can use Composer Patches plugin to update your code with recent patches available to issues queues.

Re-rolling patch #14 for compatibility with 8.x-2.7

Re-rolled patch #11 with failing test case fixes and improvements.

@Morbus Iff, The issue mentioned with comment #4 was belongs to the patch submitted with issue queue #3019539 ✨ Expand Accept.js to include Accept.js UI Needs review

Since, the patch was developed in context of Authorize.net (Accept.js UI) API, which accepts expiry_year in format of YY, while the Commerce Payment stores that value in YYYY format. which creates conflict on Payment Method edit, that the default year won't get select as expected.

The bug was fixed with the most recent patch update #38 ✨ Expand Accept.js to include Accept.js UI Needs review

we can close this issue now.

I've updated patch #37 in order to fix a bug with this patch.

to reproduce:

1. Head to user/#/payment-methods
2. Create a new payment method with Authorize.net (Accept.js UI)
3. On success, edit this newly created payment method.
4. Regardless of what YEAR you have specified (while adding the payment method), the year on the saved payment method will always show the first item in the select dropdown (in this case: 23).

The old patch overrides Commerce Payment's default expected expiry year storage format i.e. YYYY to YY. so, the payment methods created by Authorize.net (Accept.js UI) gateway will store year in YY format instead of YYYY. This because the Accept.js UI form allows YY for the expiration year, and that value followed in the whole processing of validation and storing to database.

The patch #2 re-rolled with improvements.

We have exposed Commerce License events to Commerce Email's "Add email" event list. now users can create Email events on Commerce license's events.

Here is the patch for the requirement of this issue, hopefully it will help.

vipin.j → created an issue.

Small tweak in the patch to remove one of the WCAG 2.1 issue.

Fixing failed test cases.

Here's a patch to fix configurations.

vipin.j → created an issue.

Here's a patch to fix configurations.

vipin.j → created an issue.

Here's a patch to fix configurations.

vipin.j → created an issue.

Here's a patch to fix configurations.

vipin.j → created an issue.

Here's a patch to fix configurations.

vipin.j → created an issue.

Here is the patch to update missing details.

vipin.j → created an issue.

Patch #192 was fixed for failure while patch application, due to test case file changes DefaultsSectionStorageTest.php, in RC1 release. This patch is applicable for version 10.1.x-dev.

Patch #7 re-rolled for version 3.0.x-dev.

The patch #18 is re-rolled with updates for release ^2.35 compatibility.

This patch will create an unordered list of mail attachments on a mail log view, if that email has attachments.
hope this will be helpful.

This merge request was missing Drupal 10 migration support in composer.json file, which further affects building dependencies in site's composer.lock. which means currently in site's composer.lock the require is still lock to D8 & D9, i.e. "drupal/core": "^8 || ^9".

So, to migrate from existing Drupal 9 site to Drupal 10, it should also be compatible with ^10, which can be managed by module's composer.json.

with #7 commits, now the generated .diff file is failing with composer-patches on release version 8.x-1.1, because of the # Information added by Drupal.org packaging script on 2020-06-23 details in commerce_checkout_order_fields.info.yml, conflicts with the changes done by the commits.

I have tried to fix the composer patch application failure with this patch. this will help in removal of conflict with dependencies and the last commits. We still wait for the merge request to be approved for next stable D10 release.

vipin.j → made their first commit to this issue’s fork.

vipin.j → made their first commit to this issue’s fork.

vipin.j → made their first commit to this issue’s fork.

This patch will add Drupal 10 and PHP 8.1 support. the FedEx API has been replaced from NicholasCreativeMedia/FedExPHP to JeremyDunn/php-fedex-api-wrapper → with this patch.

vipin.j → created an issue.

Rerolling this patch based on #81 for 2.0.x compatibility.