Open barryvdh opened 8 years ago
delatbabel
commented
8 years ago In fact it's properly called cardReference, although many gateways call it a card token. Properly speaking, token in current omnipay parlance means an access token, e.g. with PayPal, Allied Wallet and some other gateways an OAuth Bearer Token is required in the HTTP header for authentication purposes.
judgej
commented
8 years ago I like the idea of cardReference. token is so much more ambiguous, since there are tokens for many other aspects of the gateways too. Token has some precedence in OmniPay, I suspect due to it being called "token" by Stripe some three years ago.
Some of these card references are one-use tokens (e.g. Sage Pay) and some can be saved for future use (e.g. PAYONE, and that even looks like a credit card number, but in a custom range).
judgej
commented
8 years ago As well as the card reference/card token to pass to the server APIs, there are some other aspects that it would be good to standardise. At the moment for the front end, I'm using a response message with transparentRedirect set to indicate "this data is used somehow on the web client". The data would then be in getRedirectData() for use in that front end, also the getRedirectUrl(). Now, how that data is used will vary immensely between gateways, but usually it represents hidden fields on a form in the client, or parameters used in an AJAX request.
They don't generally include non-hidden fields that the end user is to fill in - that's a bit of front-end stuff that the developer needs to dig out of the gateway documentation (which is unacceptable IMO, because digging into these development guides can be quite a lot of work). So I'm not sure if there is some standard way we can put some helpful details together on how the client-side is constructed, with the help of OmniPay?
judgej
commented
8 years ago It has occurred to me that many (most?) gateway methods for tokenising a card, will also return the expiry date and a version of the card number for identification purposes (e.g. the card with the middle eight digits replaced with Xs). Also an identifier for the card type (probably good to translate to the OmniPay card type identifier). It is useful to be able to grab these for storage.
For tokens that are long-lasting, the expiry date can be used to expire the card in the merchant application automatically. The munged card number and card type identifier is useful to index cards when a user has multiple (or even one, as a reminder) card tokens stored on the merchant site.
kwilliams
commented
7 years ago You have my vote on this!
I have a couple of quick notes and questions:
We have been using the WePay gateway. https://www.wepay.com/developer/process_payments/tokenization-custom-checkout
They require you to use their javascript client to perform the CORs enabled ajax request to retrieve a token. I'd assume that the browser client is out of scope of this library in order to avoid these types conflicts.
Their client also supports tokenization of bank accounts https://stage.wepay.com/developer/reference/bank-account-tokenization
I noticed issue #245 come through in regards to adding bank account tokenization. Would these be considered in the same interface?
If so what about using the term fundingSource? I don't think that cardReference is generic enough to handle both implementations fluently.
PayPal likes the term funding source (https://www.paypal.com/ca/webapps/mpp/popup/funding-mix-education)
As more gateways provide a way to tokenize creditcard details, should we create some standard for this?
Problem is that the javascript is generally tied to a form, so nut sure if that fit's the idea of an API. But a general 'token' field could be standardised. Not it's usually called 'token', but this could be confused with token billing?
See https://github.com/thephpleague/omnipay-authorizenet/issues/41 https://github.com/thephpleague/omnipay-stripe#stripejs https://github.com/thephpleague/omnipay-braintree#basic-usage (needs an API call to actually generate a token before it can use the JS)