Declined card throws exception in OrdersCaptureAsync()

[ianw1223]

When testing the declined card scenario by using CCREJECT-REFUSED in the payer name field, OrdersCaptureAsync() throws an exception.

Surely a refused card is an expected scenario, not an exception. OrdersCaptureAsync should return an informative result that we can handle as a normal part of our workflow, rather than having details buried within the exception.

[LeonarthusMectus]

Hey @ianw1223

If you could provide any additional details around what sort of exception you're seeing, that would greatly help us determine what might be going wrong when you're doing your negative testing.

[ianw1223]

Thanks @LeonarthusMectus. The issue is more one of design rather than a bug, and specifically whether throwing errors is an appropriate way to encode businsss logic.

For example, the PayPal-DotNet-Server-SDK includes the method OrdersController.OrdersCaptureAsync() which returns Task<ApiResponse<Order>>. In that, if the credit card is declined for common reason such as incorrect CVC, insufficient funds, etc., the PayPal servers will return an HTML 422 indicating that it could not be processed. BUT within OrdersCaptureAsync() it then turns around and throws a .NET exception which I must catch. I then need to parse deep into the HttpContext of the exception to find out what the problem was and present that description back to the user so they can fix it.

What I am proposing is that in this very normal scenario of a declined payment, OrdersCaptureAsync() should return that result within its response of type ApiResponse<Order>, and not throw an exception. (Presumably this philosophy would need to be applied elsewhere in the package too.)

If you scroll down within https://developer.paypal.com/api/rest/reference/orders/v2/errors/ to the Capture Orders section, notice the many detailed issues that are listed within UNPROCESSABLE_ENTITY. Those are what I want the SDK to return.

All that said, I may be missing a key point. And I do notice that despite the fact that this is a "0. beta" release, it seems that all the other similar packages are deprecated and point people here. So breaking changes like this might not be welcome by some.

[runxc1]

This project is just starting to be used. It would be a lot more helpful to not throw an error but instead return a success status that it failed and the reason why. Having to catch some error that is thrown complicates the logic. I'd only expect to catch an error if the called failed (aka paypal was down) or some other networking issue.

[runxc1]

As a note on this the example application found here which is supposedly using this library would not work

https://developer.paypal.com/studio/checkout/standard/integrate

It is directly passing the results from OrderCaptureAsync back to the UI. The UI is expecting a details property that does not exist on the return object. The details property is what contains the error information. Currently no good way to get the error information back from a call.

[LeonarthusMectus]

Hey folks,

Thanks for taking the time to respond with the additional context, discussion points, and even the call out to the issue in the demo app. The team is going to take a deeper look at this to determine what we may be able to do to address these concerns, and also correct the demo app.