-
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
Stripe Payment Intents - Update transfer_data option #3317
Stripe Payment Intents - Update transfer_data option #3317
Conversation
7421aad
to
449b390
Compare
@@ -207,10 +207,10 @@ def setup_future_usage(post, options = {}) | |||
end | |||
|
|||
def add_connected_account(post, options = {}) | |||
return unless transfer_data = options[:transfer_data] |
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.
Sorry if this was already discussed elsewhere, but wouldn't this be a backwards-incompatible change for other users of this gem? What's the driving need for us to change the option keys here?
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.
I noticed as I was about to add this as a GSF that it seems pretty rare for other gateways to have a hash as an option for something pretty simple like this set of fields, so I thought it might be good to simplify it. It seems low risk since I just added this gateway within the last 2 weeks or so, but you're right that this would be backwards incompatible. To be safe, I can close this out and just handle on our end though in case anyone is already using this if you all think that's the better approach!
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.
Ah, didn't realize it was a change to that recent an addition. If there hadn't been a gem release yet for that code I would say we're probably safe, but if it had already been released with that as part of the public API we'd probably want to err on the safe side.
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.
Yeah, doublechecked, and the gateway addition is at the very top of the changelog HEAD, so doesn't look like it's been released in a version yet
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.
LGTM, thanks for double-checking the release history!
Rather than requiring a user to send in a hash with transfer data, this PR changes to use individual `transfer_destination` and `transfer_amount` fields instead. Remote: 24 tests, 103 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed Unit: 6 tests, 42 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
449b390
to
210fcfe
Compare
thanks @bayprogrammer ! |
Rather than requiring a user to send in a hash with transfer data, this PR changes
to use individual
transfer_destination
andtransfer_amount
fields instead.Remote:
24 tests, 103 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
Unit:
6 tests, 42 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed