-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Concatenate card and customer token #3144
Conversation
1d4591e
to
f12aff6
Compare
@@ -206,7 +215,11 @@ def unparsable_response(raw_response) | |||
end | |||
|
|||
def token(response) | |||
response['token'] | |||
if response['token'].start_with?('cus') | |||
"#{response.dig('card', 'token')}+#{response['token']}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no real standardization, but unless you think +
is particularly suited for this gateway, let's use one of the more common separators, either ;
or |
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, since prior authorizations only consisted of the customer token, that should be the first element so that splitting old tokens will still parse them correctly. Maybe that's not actually applicable for this gateway but should be followed generally when adding these things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for using a common separator.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
cab09f9
to
ad8ee2d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
ad8ee2d
to
997c0a8
Compare
Pinpayments handles stored cards by assigning them to a user. It seems that if
a card is associated with a user the card must be used with the customer ID
rather than the card's, and since a card can only be associated with one user,
it's not clear that the card ID generated when a card is stored will ever
actually be reusable (see the Customer API docs since cards are irretrievable once they are replaced.
The possible use case for stored card IDs is that customers may have multiple
cards if one is set as primary. Other stored cards may not be able to be used
until/unless they are set as primary.
Remote tests: 16 tests, 46 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
Unit tests: 37 tests, 112 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed