Use no-meteor functions for payment capture and refund methods

[jamesporl]

Impact: major
Type: refactor

Issue

Payment capture and refund are currently done by creating Meteor methods named using processorName + methodName within a payment plugin . As we intend to minimize using Meteor, we want to use no-meteor functions instead by registering them into the functionsByType parameter in a plugin's register.js file.

Solution

Instead of creating processor/method-name methods, payment plugins will need to register no-meteor functions in the register.js using the functionsByType parameter. In particular, payment plugins need to create the following functions:

${processor}CapturePayment
${processor}RefundPayment
${processor}ListRefund
${processor}DeAuthorizePayment

Breaking changes

Payment plugins that use Meteor methods for capture and refund will not be compatible with this PR.

Testing

As admin, enable example payment method in the admin dashboard.
As customer, create an order and pay with the example payment method (this can be done in the classic UI).
As admin, open the newly created order in the dashboard panel for Orders.
Click Approve, and Capture. See that Captured Total is updated.
In the same order, enter a refund amount and click Refund. Check that the order in the database has additional success transactions.

2
As admin, enable Stripe payment method in the admin dashboard and enter correct credentials.
As customer, create an order and pay with Stripe payment method (this can be done in the classic UI).
As admin, open the newly created order in the dashboard panel for Orders.
Click Approve, and Capture. See that Captured Total is updated.
In the same order, enter a refund amount and click Refund. See that the refunded amounts are displayed in the order.
For Stripe, you can verify the amounts captured and refunded in the Stripe merchant dashboard.

[brent-hoover]

@ajporlante I don't understand this part

need to create the following functions:

${processor}CapturePayment
${processor}RefundPayment
${processor}ListRefund
${processor}DeAuthorizePayment

Why do we care about what the methods are called? Couldn't they just be in a nested object that defines capture/refund/list etc. under a key for the payment provider? I would like to get away from using the names as keys because this has always brittle and causes problems with payment providers who have non-javascript safe characters in their names

[jamesporl]

@aldeed @zenweasel Reworked it as you requested. You can check, then I can proceed with removing the Meteor method files and rewriting the tests.

[aldeed]

@ajporlante See my one minor comment but otherwise looking beautiful

[jamesporl]

@zenweasel This is ready for another review. I have reworked as @aldeed suggested, removed the unnecessary Meteor methods and tests, and rewrote the unit tests for the new no-meteor functions.

[brent-hoover]

Tested. Verified working. Great work. 🎉

[aldeed]

@ajporlante Looks like one eslint error to resolve before we can merge this. https://circleci.com/gh/reactioncommerce/reaction/32460?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-checks-link

[jamesporl]

@aldeed Fixed.