Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why this project #1

Open
DimeZilla opened this issue May 24, 2019 · 0 comments
Open

Why this project #1

DimeZilla opened this issue May 24, 2019 · 0 comments

Comments

@DimeZilla
Copy link

DimeZilla commented May 24, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant