Hi, Big fan! I really appreciate all of the work you all did to put Omnipay together.
I work for a company that is building an application that is sort of a "merchant marketplace" where essentially we are providing a platform for non-profits to create accounts and solicit donations. Like many others that have discovered Omnipay, we built our application and then discovered that we didn't totally love the payment processor we were using.
So, we began to build Omnipay into our platform but quickly noticed that there wasn't much in support for a common api for creating accounts and users with the payment processor platforms. This PR lays the foundation for that support.
If this fork is accepted, driver developers should now think of their drivers as providing 3 gateways:
Payment - This is the standard payment gateway that all drivers currently support. Here you would processes purchases, create credit cards, etc.
Account - This is a new gateway for finding, registering, modifying merchant accounts.
User - This is a new gateway for finding, registering, modifying users.
Accessing the gateways would follow the same conventions from before but unlike Omnipay\Omnipay::create('[name]') to retrieve the payment gateway, you would use Omnipay\Omnipay::user('[name]') and Omnipay\Omnipay::account('[name]') to retrieve the user gateway and the account gateway. In the PR, ::create was left alone but we also added ::payment as an alias to create.
For the GatewayFactory to resolve the payment gateway, it will look for a gateway with the following namespace pattern: Omnipay\[name]\Gateway. As you can see, this was left alone. But for User and Account gateways, the Gateway factory will look for Omnipay\[name]\User\Gateway and Omnipay\[name]\Account\Gateway respectively.
To support these new gateways, we added AbstractAccountGateway and AbstractUserGateway. Again, my goal in this PR was to not break all of the existing v3 drivers, thus, some of the naming might look funky. For instance, AbstractGateway is still the class a driver would extend to build their Payment Gateway. And now, these three abstract classes extend from AbstractGenericGateway. I think in an ideal world, we'd have an AbstractPaymentGateway and then all of these classes would extend AbstractGateway, but I digress.
Further, AbstractRequest now extends AbstractGenericRequest and the new gateways can use requests that extend this new base abstract class.
To support testing of the new gateways, we forked the omnipay-tests package to radcampaign/omnipay-tests and added AccountGatewayTestCase and UserGatewayTestCase. If this PR is accepted, I'll submit a PR for this fork as well.
For an example of how a driver might look with this new PR - we are actively working on a wepay driver that can be found at radcampaign/omnipay-wepay. Please keep in mind though that this is under active development.
Thank you much! I hope that this PR furthers this project in productive way.
Hi, Big fan! I really appreciate all of the work you all did to put Omnipay together.
I work for a company that is building an application that is sort of a "merchant marketplace" where essentially we are providing a platform for non-profits to create accounts and solicit donations. Like many others that have discovered Omnipay, we built our application and then discovered that we didn't totally love the payment processor we were using.
So, we began to build Omnipay into our platform but quickly noticed that there wasn't much in support for a common api for creating accounts and users with the payment processor platforms. This PR lays the foundation for that support.
If this fork is accepted, driver developers should now think of their drivers as providing 3 gateways:
Accessing the gateways would follow the same conventions from before but unlike
Omnipay\Omnipay::create('[name]')to retrieve the payment gateway, you would useOmnipay\Omnipay::user('[name]')andOmnipay\Omnipay::account('[name]')to retrieve the user gateway and the account gateway. In the PR,::createwas left alone but we also added::paymentas an alias to create.For the GatewayFactory to resolve the payment gateway, it will look for a gateway with the following namespace pattern:
Omnipay\[name]\Gateway. As you can see, this was left alone. But for User and Account gateways, the Gateway factory will look forOmnipay\[name]\User\GatewayandOmnipay\[name]\Account\Gatewayrespectively.To support these new gateways, we added
AbstractAccountGatewayandAbstractUserGateway. Again, my goal in this PR was to not break all of the existing v3 drivers, thus, some of the naming might look funky. For instance,AbstractGatewayis still the class a driver would extend to build their Payment Gateway. And now, these three abstract classes extend fromAbstractGenericGateway. I think in an ideal world, we'd have an AbstractPaymentGateway and then all of these classes would extend AbstractGateway, but I digress.Further,
AbstractRequestnow extendsAbstractGenericRequestand the new gateways can use requests that extend this new base abstract class.To support testing of the new gateways, we forked the omnipay-tests package to radcampaign/omnipay-tests and added
AccountGatewayTestCaseandUserGatewayTestCase. If this PR is accepted, I'll submit a PR for this fork as well.For an example of how a driver might look with this new PR - we are actively working on a wepay driver that can be found at radcampaign/omnipay-wepay. Please keep in mind though that this is under active development.
Thank you much! I hope that this PR furthers this project in productive way.