You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
In this fork, 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 with these changes 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 these changes - 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.
The text was updated successfully, but these errors were encountered:
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.
In this fork, 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 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 with these changes 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 these changes - 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.
The text was updated successfully, but these errors were encountered: