Inconsistent value for "Instrument" when paying with invoice

[antonhansson]

The PaymentInstruments recognized by the SDK are listed here: https://github.com/SwedbankPay/swedbank-pay-sdk-dotnet/blob/develop/src/SwedbankPay.Sdk/PaymentOrder/Paid/PaymentInstrument.cs#L116

The relevant values for invoice payments are "Invoice-PayExFinancingSe", "Invoice-PayExFinancingNo" and "Invoice-PayMonthlyInvoiceSe".

However we're observing the following behavior:

• Create a PaymentOrder which has the following AvailableInstruments:

  "availableInstruments": [
    "CreditCard",
    "Invoice-PayExFinancingSe",
    "Swish",
    "Trustly",
    "ClickToPay"
  ],
  

• Go through the payment flow, using the invoice option in the UI.
• When confirmed/successfull, the PaymentOrder has the following value in PaymentOrder.Paid.Instrument:

    "instrument": "Invoice",
  

This seems inconsistent, but also appears to be documented behavior. I'd expect one of the values from AvailableInstruments here, or at least a value listed in the PaymentInstruments class. Using the SDK, this gets parsed into a PaymentInstrument with Name and Value "Invoice".

I noted that the History.HistoryList also seems confused about the right value for Instrument. We have the following events:

        {
          "name": "PaymentInstrumentSelected",
          "instrument": "Invoice-payexfinancingse",
          ...
        },
        {
          "name": "PaymentAttemptStarted",
          "instrument": "Invoice",
          ...
        },
        ...

Is there a reason for this inconsistency?

This mostly seems like an issue with the underlying API and not the SDK itself, but perhaps you can get in touch with the API developers directly and discuss this. If this behavior needs to remain, at least it seems like the "Invoice" instrument should be explicitly listed in the SDK and the behavior more clearly documented.

Thanks!

[Wlundqvist]

@antonhansson
Thank you for noticing. This issue stems from the API itself, not the SDK. We are aware and have it in our backlog, but it won't be changed in the immediate future in order to avoid breaking existing integrations. Corrections will come in future API versions, most likely 3.2.