[RFC] Payment Integration

[Eponymi]

So payments and gateways are a lot more complicated than I had thought! As such, some more
detailed thought and community input is necessary before writing a bunch of code. This WIP
PR has two sections:

1. Concerns: concerns are two-fold. They will first attempt to identify problems.
   Secondly, an architectural or design-based solution should be offered. Concern solutions
   should be vague in nature; that is, they should not contain any code or implementation
   details. They just say what's going to be done. Concerns should be ratified by the
   community before their solutions are included in the pull request. Any concern with a
   check mark is considered ratified.
2. Solutions: a Concern must be associated with a solution outline in the form of a
   task list, so that specific tasks can be assigned and completed. The Solution task list
   should be a concerted effort to clearly define the steps necessary to implement a
   proposal.

Concerns

• Gateway Implementation: To keep the bundle decoupled, while also facilitating easy
  extensibility, a Gateway design must be decided upon, including Dependency Injection,
  Form View Rendering, and progressing the state of a Payment.
• Payment Source Modeling: Payments may come from different sources; e.g.
  CreditCard, ACH, API, WireTransfer, BitCoin, or Physical Transference. A Payment
  Source's job is to give a Payment an object to be used in a communication with a Payment
  Method. It must provide a valid object for the particular Method to use, whether that be
  a Source accepted by the Method's gateway, or an otherwise approved mechanism.
• Payment Processing: some abstract method of pushing payments through their states
  must be defined.
• Native Gateway Bridging: If Gateways are services tagged with sylius.gateway,
  there must be functionality for pushing payments through their states via methods of the
  native gateway.

Solutions

• Gateway Implementation:
  • A GatewayInterface, which will stipulate what methods a Gateway must define to
    push a payment through the available states.
  • A GatewayChain whose purpose is to maintain a registry of gateway services (see:
    Working with Tagged Services" Cookbook Entry).
  • A Factory whose purpose is to facilitate creation of Gateway services in the
    Sylius domain using other libraries/bundles.
  • A Service Tag (sylius.payment_gateway) which may be used in conjunction with the
    Factory
  • A Compiler Pass that will retrieve all tagged services, validate them, and
    register them with the GatewayChain
• Payment Source Modeling:
  • A PaymentSourceInterface, which will facilitate communication and transformation
    between the Source and the Method.
  • Source Typing: before a source can be used, it must be recognized by the Payments
    Bundle. This enables us to keep track of transformation methods, and allows us to
    define and retrieve associated services, like a credit card form.
• Payment Processing
  • A PaymentProcessorInterface will stipulate that Processors must have methods for
    each payment state. The methods will expect a boolean, and if true, push the payment
    to the target state.
  • A default PaymentProcessor will be implemented that simply returns true for all
    methods.
  • A PaymentProcessor may have a $gateway (an instance of BridgedGateway; see
    below). If it has a bridged gateway, the responsibility for returning the boolean will
    be passed along to the gateway.
• Native Gateways:
  • To bridge to native gateways, for each payment state a call method and a
    verify method will be defined. When the PaymentProcessor
  • A MethodResolver will take the strings specified in call and verify and
    turn them into actual PHP callables, a la the ControllerResolver.

[Eponymi]

Alright, seems like this RFC isn't really engaging anyone. I'm gonna go ahead and use a hardcoded payment method. As such, it probably makes sense to close this issue and allow the maintainers and core contributors sort out abstracted payments.

[cordoval]

you should reopen this and let the time judge 👶 having it out of the radar is wrong, unless this was solved already but it was hard to find, also if you did the hard coded stuff, would be good to share it on a gist or somewhere

[mattjanssen]

I agree that this issue of abstracting the payment processing system is critical to making this a flexible and extendable library. Omnipay is a decent start, but adding the Source component gets us all the way to the view, which makes this a much more complete package.

[makasim]

There was discussion about integration payum + sylius. Payum more like complete package then just payment lib. Payum bundle provides nice integration into symfony2 framework.

I want mention it here because as I see you want to do something similar payum already does.

[makasim]

I've started a payum + sylius integration PR #275. Feedback is highly appreciated.