Replace the payment API with Payment 8.x-2.x

Problem/Motivation

#326269: Split payment method pack into multiple modules, #2183813: Make payment method plugins configurable, and #700270: Remove hook_uc_order('submit') as it is never called for redirected payment methods have one thing in common: the current payment API is not suffiently abstracted. This is nothing strange, as it is hard to decouple such things and building a properly abstracted API takes a lot of work. However, it does impose limitations and fixing or especially rewriting the current API would be a duplicate effort, seeing as there are alternatives among Drupal's contributed modules.

Proposed resolution

I suggest Ubercart's payment API is replaced with Payment 8.x-2.x, which can also already be used with Ubercart 7.x-3.x through Payment for Ubercart. This is a reusable payment processing platform that is fully object-oriented (and therefore easily maintainable, extensible, and testable) and integrates with many useful Drupal 8 features.

It solves #326269: Split payment method pack into multiple modules by explicitly stating that no payment method will ever be added to the 'core' package, except for the existing Basic payment method which does not depend on any third party services.

It solves #2183813: Make payment method plugins configurable by using two plugin types and an entity type. This ensures maximum flexibility and testability, allowing developers to write payment methods that are linked to their own systems, or that can be infinitely instantiated and configured from the user interface.

It solves #700270: Remove hook_uc_order('submit') as it is never called for redirected payment methods by not caring about how payment methods execute payments at all. This ensures that it doesn't accidentally limit a type of payment method that none of the maintainers would ever think of, but that may exist in other countries.

It also aims to centralize payment method development as much as possible by leveraging Drupal modules and external libraries (such as Omnipay and PaymentSuite) that contain APIs to connect with PSP services. This lightens the load on the developers, because they won't have to learn another third party web service's API anymore. It also means changes in those web services will be dealt with much more quickly, as less code will have to be maintained. This lets us develop our platforms with much more agility.

It supports, but does not require, complex workflows where payments go through different states or get different statuses before they are completed. It uses a few simple, but very powerful events (hooks and Symfony events for now, but Rules events will be added once Rules for Drupal 8 is done) to allow developers to customize the payment processing workflows.

It uses Currency 8.x-3.x for multicurrency support, and this goes a long way to fixing #1097668: Multicurrency support.

Remaining tasks

T.B.D.

User interface changes

• Payment includes a dedicated payment overview at admin/content/payment
• Payment method administration will no longer be part of Ubercarts administration pages, but can be found at admin/config/services/payment/method.
• Payment method plugins implement PluginFormInterface, and as such any form elements that allow payers to enter payment-specific or payment-method-specific information (such as credit card numbers, or the bank they want to pay through) can be easily embedded into other forms with a few lines of code to instantiate payment method plugins and call the build, validate, and submit handlers.
• Ubercart could even use the payment method selector plugins that come with Payment. It can also choose not to and provide its own, without compromising the payment processing workflow.

API changes

The entire Ubercart payment API will be replaced with Payment's.