klarna / klarna-mobile-sdk

Klarna Mobile SDK for iOS
https://docs.klarna.com/mobile-sdk/ios/
Apache License 2.0
28 stars 12 forks source link

Provide error enumeration instead of strings for error handling #59

Open d4nielRV opened 4 years ago

d4nielRV commented 4 years ago

Is your feature request related to a problem? Please describe. As part of the Flows & Errors Handling documentation: https://developers.klarna.com/documentation/in-app/overview/inapp-sdk-flows/ you provide a list of cases which should be handled by the developer such as Rejected Authorize or Invalid Client Token. In that documentation:

func klarnaFailed(inPaymentView paymentView: KlarnaPaymentView, withError error: KlarnaPaymentError) {
        if error.name == "InvalidClientTokenError" {
          // Client token used to initialize the SDK is invalid.
           // Merchant should get a valid client token and use it to initialize the SDK again.
        }
    }

In the callback klarnaFailed you provide as parameter an instance of KlarnaPaymentError which contains a couple of attributes: action and message. Those properties have to be checked in order to detect the kind of error, but since they are Strings we don't have a list of the errors that could be returned by the SDK.

Describe the solution you'd like Defining an enum the kind of error would let us to keep a clear code to handle those errors. For example, following your documentation, the error.name ShowFormFalseError is being used for multiple errors depending on the action (Load, Authorize, etc.).

Current status:

func klarnaFailed(inPaymentView paymentView: KlarnaPaymentView, withError error: KlarnaPaymentError) {
        if error.action == "Authorize" && error.name == "ShowFormFalseError" {
           // user is rejected when authorizing the payment.
           // Merchant should remove the Klarna view and stop the payment process.
        } else if error.action == "Load" && error.name = "ShowFormFalseError" {
          // The selected payment method is invalid.
           // Merchant should set a valid payment method for SDK and initialize the SDK again.
        }
    }

Our proposal:

func klarnaFailed(inPaymentView paymentView: KlarnaPaymentView, withError error: KlarnaPaymentError) {
   switch(error.type) {
      case .invalidPaymentMethod:
         // The selected payment method is invalid.
         // Merchant should set a valid payment method for SDK and initialize the SDK again.
      case .rejectedAuthorization:
        // user is rejected when authorizing the payment.
        // Merchant should remove the Klarna view and stop the payment process.
   }
}

Actually comparing Strings is not so secure solution because in case any developer or even you as SDK provider has any typo, the error handling will fail.

Describe alternatives you've considered At least provide a list of possible values for both action and name properties.

Additional context N/A

gbanfalvikl commented 3 years ago

Hi!

We'd love to provide an enumeration for error types. This is for our sake too. However, a number of them (most, in fact) come from the backend and we can't insure that all the other cases are (or will be) covered.

We're looking into offering some form of string typealias for error type with the most common values being predefined – effectively making integration look a lot like your code.

This might take a little bit of time, however. We'll keep the issue open and update you as it comes out!