SDK Improvements

[Charchad]

Hi,

I was wondering if you are planning to improve the error handling of a given transaction, by maybe showing in the UI a more detailed error than just "Your payment could not be authorised".

We want to show to the users a detailed message explaining why a payment failed, but from the SDK we are only getting an exception with a message with some numeric error. e.g:

declined (Declined, error code: 1403)
card blocked (Declined - card blocked, error code: 1404)

Note: These messages are not localised, they are always in English.

And about localisation, would it be possible to allow us to set the language that should be used by the SDK? Now it is taking the language from the device, but for those app (as ours) where you can customise the language within the app, then the language can be different.

Thanks! Germán

[BasilAch]

Hi @Charchad

Thank you for your questions.

Regarding error messages:

We do not plan to show more detailed error messages, as in many common cases we cannot provide more information (just "declined"), and in others it can even be confusing. We also do not normally suggest our merchants try to do it. That said, you are of course free to implement your own error handling if you want, using the suppressCriticalErrorDialog option.

We are looking into providing consistent codes across our platforms, meaning that we would return the same named error codes as our JSON API does. We will, however, not provide localized messages for these codes. The messages you see now are sometimes coming directly from third party backends and can change at any time. Integrators therefore must not rely on them.

Regarding language override:

This is a general payment platform option. It is therefore not part of the SDK-specific options, but you can just set it like other options in the transaction init request (parameter language). Please note that currently the SDK supports en, de, fr, it, with support for additional languages in the works.

Kind regards, Basil

[Charchad]

Hi @BasilAch,

Thanks for the reply.

We are looking into providing consistent codes across our platforms, meaning that we would return the same named error codes as our JSON API does. We will, however, not provide localized messages for these codes. The messages you see now are sometimes coming directly from third party backends and can change at any time. Integrators therefore must not rely on them.

Is there an estimate for when this change will be made? Right now this is blocking us to move to the native SDKs from the current implementation that relies on the JSON APIs.

This is a general payment platform option. It is therefore not part of the SDK-specific options, but you can just set it like other options in the transaction init request (parameter language). Please note that currently the SDK supports en, de, fr, it, with support for additional languages in the works.

This did the trick, thanks again

Cheers, Germán

[BasilAch]

Hi @Charchad,

There will be a first release in which the JSON error codes are added to the current exception/error. You can show your own messages based on these codes. This change is scheduled for the end of this year. The exception message and the numeric code will be the same as you currently see. In a later release, we will make some bigger changes under the hood, and you will then also receive more consistent exception messages. For this there is no timeframe but in any case, as I've said above, they will still be in English only and are not meant to be parsed or relied on.

Regards, Basil

[Charchad]

okay, thanks!

[Charchad]

@BasilAch I have one last question regarding this topic. Is there a place where I can see all the possible numeric error codes? And maybe some description of what they mean?

[bacherma]

Hi @Charchad. First, happy New Year! FYI, we have released 2.5.0 (Android, iOS) of the SDK with error names. I hope they turn out to be useful.

There is no documentation on raw error numbers as they can be forwarded from third parties and are sometimes ambiguous without additional context. If you must implement your own error handling, please use above-mentioned error names.

Cheers, Basil

[Charchad]

Hi @Charchad. First, happy New Year!

Hi @bacherma Happy new year!

FYI, we have released 2.5.0 (Android, iOS) of the SDK with error names. I hope they turn out to be useful.

Thanks! I will take a look now

[Charchad]

Hi @bacherma,

Can you please explain how and where do you get these new error names? I'm seeing that TransactionListener still reports an exception when onTransactionError is executed

[Charchad]

Never mind, I see that is inside BackendException

[Charchad]

Okay, now I was able to test it, but I see something strange... almost every time a payment fails, I see as name "UNKNOWN_ERROR" despite the reason is clear (I used an invalid card number or the card is expired)

I actually see different error codes, eg: 1004, 1402, 1403 (which based on this page https://docs.datatrans.ch/v1.0.1/docs/api-response-codes they are okay) but as I said the name is always "unknown error"

[bacherma]

Hi @Charchad , thanks for bringing this up. We indeed found an issue in the final Android build that can cause the mapping to fail and default to unknown. We have uploaded and tested 2.5.1. Please verify your use cases with this version, all of them should return a correct error code.

[Charchad]

Hi @bacherma, I just tested the version 2.5.1 and yes now it works as expected. Thank you!

[bacherma]

Thanks @Charchad, great to hear. 2.5.1 has now been officially released. I'm closing this ticket. if you have further issues, please open a new one.

Cheers, Basil