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

Card / Customer splitting #183

Open
barryvdh opened this issue May 18, 2018 · 5 comments
Open

Card / Customer splitting #183

barryvdh opened this issue May 18, 2018 · 5 comments

Comments

@barryvdh
Copy link
Member

For many projects, the 'CreditCard' object is used for just customerData. We could split it up, but what would be the best way to do this, without BC breaks?

Gateways use getCard and users use setCard, so we can't just add a Customer object by default.

The most that bugs me is the name of the object, and the validation of the object. So could we just use the same object but allow both card and customer as objects? And change the validation a bit?

eg. passing customer would behave the same as card, by setting card internally
And validate() could behave different when parameters are passed.

See also #80

@judgej
Copy link
Member

judgej commented May 18, 2018

I think the approach should be deciding what the new interface should be, then mapping the old CreditCard object onto the new interface internally. The CreditCard object could be deprecated (with longer term support for some time) but ultimately there would be a better interface to use, with a better division of data into value objects: address, person, business, payment types/sources classes (credit card, debit card, direct debit, magnetic stripe, giropay, temporary AJAX token, repeat transaction, saved card token etc). I think V4 gives us a chance to take a step back and look at the whole API with a fresh look, as payment gateways have moved on a long way since Omnipay was first created. Mapping the V3 API to a more robust API would be built-in, or even installed as a separate V3-compatibility extension.

Omnipay does not have to provide all features of all gateways, but have a better idea of what features gateways supply and people want to use, so I believe the interface needs to be abstract enough to be able to plug in custom handling classes for all these features.

That's my 2p worth.

@barryvdh
Copy link
Member Author

I made a cosmetic change here: #185
Ideally those would be split but that would be a big breaking change.

@xini
Copy link

xini commented Nov 29, 2018

What is the status of this? And what exactly happened to #80? Thanks.

@barryvdh
Copy link
Member Author

That was reverted, because we decided to do a minimal 3.x upgrade.

@xini
Copy link

xini commented Nov 29, 2018

Thanks @barryvdh. What are the plans and timeline to integrate this?

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

3 participants