fix:catch lost platform error when converting ios confirmed payment intent errors

[StephanWalters]

Addresses: https://github.com/BreX900/mek-packages/issues/72

Credit to: @jermaine-uome as this isn't my fix, but i see others were facing the same issue, so i created a PR. https://github.com/BreX900/mek-packages/issues/56

[joelsuite]

Hi, I was just testing this fix on a project we have that uses mek_stripe_terminal and I noticed something slightly off about the ios errors.

While the errors are now coming through properly with the correct message on the TerminalException that results, the apiError field appears to be a copy of the message field on the error for ios. This doesn't match what we see on android. Beneath, I've posted what we get on both the message and apiError fields on the error in the case of a decline because an offline pin was required for both android and ios.

ios

message: "This transaction requires chip and PIN. In testmode, using a physical test card with designated amount ending values produce specific decline responses. See https://stripe.com/docs/terminal/references/testing#physical-test-cards for details."
apiError: "This transaction requires chip and PIN. In testmode, using a physical test card with designated amount ending values produce specific decline responses. See https://stripe.com/docs/terminal/references/testing#physical-test-cards for details."

android

message: "This transaction requires chip and PIN. In testmode, using a physical test card with designated amount ending values produce specific decline responses. See https://stripe.com/docs/terminal/references/testing#physical-test-cards for details."
apiError: "ApiError(error=InnerError(charge=ch_3PVWbqBDXJ4HwByY1AlZe5zk, code=offline_pin_required, declineCode=offline_pin_required, docUrl=null, message=This transaction requires chip and PIN. In testmode, using a physical test card with designated amount ending values produce specific decline responses. See https://stripe.com/docs/terminal/references/testing#physical-test-cards for details., param=null, paymentIntent=..."

We required certain details off of the apiError in our application; our expectation is that the apiError would match in both ios and android. Please reach out if I can supply any further details that would be helpful.

[StephanWalters]

@joelsuite are you using a certain simulated test card number? Using the different cards i am able to produce the correct decline api response

[joelsuite]

@joelsuite are you using a certain simulated test card number? Using the different cards i am able to produce the correct decline api response

This is also when using a stripe test card in the testing environment, and a real card in the stripe testing environment. This also occurs when using a simulated card payment in debug mode, using the specific payment amounts to invoke payment errors in the testing environment. In this case payment screen looks like this for example, with the amount ending in .02 corresponding to an Offline Pin Required error:

[StephanWalters]

@joelsuite gotcha. These are essentially what's being returned by the respective Native SDKs, so they could just be two separate implementations. So I dont think we can assume its going to be a 1:1 mapping.(Two separate implementations). It looks like the SDKs probably prefer us using the message property. However, the error object has properties you can probably query off of. There is a code and name property you may want to use. Or expect the error object for anything else.

Last resort solution would be to map the messages to error codes.

[joelsuite]

@joelsuite gotcha. These are essentially what's being returned by the respective Native SDKs, so they could just be two separate implementations. So I dont think we can assume its going to be a 1:1 mapping.(Two separate implementations). It looks like the SDKs probably prefer us using the message property. However, the error object has properties you can probably query off of. There is a code and name property you may want to use. Or expect the error object for anything else.

Last resort solution would be to One solution would be to map the messages to error codes.

I think we're going to have to go with the last resort option because we are trying to distinguish between two errors with the same name and code (declinedByApi). That's a possibility we'd considered it's just not our first choice. I guess there's no other option though if it's what the native SDKs are returning 😂