-
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
SumUp: Add 3DS fields #5030
SumUp: Add 3DS fields #5030
Conversation
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.
It looks great, I left a couple of comments for your consideration.
@@ -139,7 +139,7 @@ def test_successful_refund | |||
end | |||
|
|||
def test_successful_partial_refund | |||
gateway = SumUpGateway.new(fixtures(:sum_up_account_for_successful_purchases)) | |||
gateway = SumUpGateway.new(fixtures(:sum_up_successful_purchase)) |
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.
❓ Question
I know you need a 3ds account coming from Europe. Is it possible to use the same 3ds account credentials here instead of this one?
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.
No, it is because the account for sum_up_successful_purchase
return a successful purchase, sum_up_3ds
return a pending purchase and we can't refund
a pending purchase.
@@ -126,9 +126,9 @@ def test_failed_void_invalid_checkout_id | |||
# In Sum Up the account can only return checkout/purchase in pending or success status, | |||
# to obtain a successful refund we will need an account that returns the checkout/purchase in successful status | |||
# | |||
# For this example configure in the fixtures => :sum_up_account_for_successful_purchases | |||
# For this example configure in the fixtures => :sum_up_successful_purchase |
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.
💭 Opinion:
I'm not sure if this comment is required (the fixtures method seems to be enough to inform that the sum_up_successful_purchase needs to be configured).
If you consider conserving it, maybe test
instead of example
could be better.
# | ||
# For this example configure in the fixtures => :sum_up_3ds | ||
def test_trigger_3ds_flow | ||
gateway = SumUpGateway.new(fixtures(:sum_up_3ds)) |
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.
❗ Modify
This :sum_up_3ds entry is missing in the test/fixtures.yml file.
To follow the structure/values required.
@@ -157,7 +162,7 @@ def parse(body) | |||
end | |||
|
|||
def success_from(response) | |||
return true if response == 204 | |||
return true if (response.is_a?(Hash) && response[:next_step]) || response == 204 |
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.
❓ Question:
why it's required to validate if the response is a Hash? what are the other possible value types?
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.
Yes, this is because the refund transaction return an Integer, If we don't verify the Hash then it breaks when doing a refund
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.
Could this possibly lead to false positives? Would the presence of a Hash
always mean a successful txn or are there failed transactions that return a hash with error messages?
Description ------------------------- [SER-798](https://spreedly.atlassian.net/browse/SER-798) This commit enable the 3DS to retrieve the next_step object. Unit test ------------------------- Finished in 27.706081 seconds. 5807 tests, 78983 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed 209.59 tests/s, 2850.75 assertions/s Remote test ------------------------- Finished in 3.182983 seconds. 1 tests, 3 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed 0.31 tests/s, 0.94 assertions/s Rubocop ------------------------- 787 files inspected, no offenses detected
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, just one question following Gustavo's about the success_from
method change.
@@ -157,7 +162,7 @@ def parse(body) | |||
end | |||
|
|||
def success_from(response) | |||
return true if response == 204 | |||
return true if (response.is_a?(Hash) && response[:next_step]) || response == 204 |
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.
Could this possibly lead to false positives? Would the presence of a Hash
always mean a successful txn or are there failed transactions that return a hash with error messages?
I think no because the second condition is the |
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!
Description
SER-798
This commit enable the 3DS to retrieve the next_step object.
Unit test
Finished in 27.706081 seconds.
5807 tests, 78983 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
209.59 tests/s, 2850.75 assertions/s
Remote test
Finished in 3.182983 seconds.
1 tests, 3 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed
0.31 tests/s, 0.94 assertions/s
Rubocop
787 files inspected, no offenses detected