This issue is about how to identify Problems – which is neccessary for correct handling in client implementations (e.g. when a payment fails beacuase of insufficient funds etc).

I'm posting this as a new issue here, but it started off as a conversation in this pull request: #94

I think Swedbank have made a good choice by transitioning over to RFC7807 for error reporting. But the way you currently have implemented and documented it makes it hard for us to use on the client-side.
E.g. this JSON response:

{
  "transactionList": [
    {
      "failedReason": "ExternalResponseError",
      "failedActivityName": "Authorize",
      "failedErrorCode": "REJECTED_BY_ACQUIRER_CARD_STOLEN",
      "failedErrorDescription": "card stolen, response-code: 43",
      "isOperational": false,
      "problem": {
        "type": "https://api.payex.com/psp/errordetail/creditcard/acquirercardstolen",
        "title": "Operation failed",
        "status": 403,
        "detail": "Unable to complete Authorization transaction, look at problem node!",
        "problems": [
          {
            "name": "ExternalResponse",
            "description": "REJECTED_BY_ACQUIRER_CARD_STOLEN-card stolen, response-code: 43"
          }
        ]
      }
    }
  ]
}

The type URI https://api.payex.com/psp/errordetail/creditcard/acquirercardstolen do not dereference to an HTML explaining the problem.
I found this documentation though for some legacy error codes:
https://developer.swedbankpay.com/resources/test-data#amount-error-testing-method
But I could not find anything in the documentation about how these URIs (types) relate to those legacy error codes.
Also RFC7807 states that:

"detail" (string) - A human-readable explanation specific to this occurrence of the problem.

But in the API we get this response back:
"detail": "Unable to complete Authorization transaction, look at problem node!",
This is hardly human readable.

Also: The problems property contains an array of error objects. How should we interpret these? E.g. can there be multiple errors? Which of them should we report back to the users/customers? The description property looks like a concatenation of the old failedErrorCode and failedErrorDescription:
"description": "REJECTED_BY_ACQUIRER_CARD_STOLEN-card stolen, response-code: 43"
Maybe this instead could be split up into multiple extension members so that it's less complex for the clients to interpret?

In summary what I really need is:

1. A list of the most common type URI's that we can expect. E.g. something similar to the list of legacy error code (https://developer.swedbankpay.com/resources/test-data#amount-error-testing-method).
2. An easy way to find a human readable description of the error to display to the customers (on web or email).
3. An implementation of these problem properties in the .NET SDK.
   You have already invited me to implement this myself and then do a pull request again.
   But it's a bit hard for me to do because you have supplied no documentation for the extension members you will be using. And it's also a bit hard to explain to our employer that we are spending time implementing an SDK that is owned by Swedbank.

Currently if a operation is not in the SDK we crash on TypedSafeEnumValueConverter when trying to read from JSON.
The SDK should either ignore it, or add it as an unknown type. Searching for operations on the string name is already supported (if I remember correctly) and as such it should be possible to add it as a unknown enum type to the list of operations.

Hi,

I noticed that there are parameters missing on the PayeeInfo class that I need to use the SDK for split settlements.

These are the parameter that are missing:
subsite,siteId

Link for reference:
https://developer.swedbankpay.com/checkout-v3/features/optional/split-settlement/

See this link:
https://developer.stage.swedbankpay.com/checkout-v3/features/optional/sort-order-payment-menu/

Having an issue with the EmailAddress class that validates in its ctor.
The regex that is used seems to not conform to RFC https://tools.ietf.org/html/rfc2822#section-3.2.4.
For example:
[email protected] validates but [email protected] does not validate, but both are valid email addresses according to spec.

I've tried with a few other email variants and it does seem that most special characters that can be used in emails cant be used at the start or end of the local-part of the email. Trying with Postman against the service directly (POST https://api.externalintegration.payex.com/psp/paymentorders) there doesn't seem to be any validation for the email. So perhaps the validation is not needed or could be turned of perhaps?

Trying to omit the Email from the RiskIndicator class for example causes a null pointer exception.

I was thinking about perhaps usage of new EmailAddressAttribute().IsValid() but it really doesn't do anything more than just checks that a @ is included and something at all is before and something is after the @. So that could be to "little" validation if there should be something.

Current <7. Breaks for all kinda of newer .net versions

We don't want it, it needs to be gone for we like NSubstite that we also have referenced in our configs.

Hi,

I want to set requireShippingAddress to false, but it seems thats itś not included in ConsumerRequest?

The test PaymentRecurTests.Payment_Card_Recur uses Operation.Verify but should use Operation.Recur.

Hello,

There is a dependency on the SwedbankPay.Sdk.Extensions package for SwedbankPay.Sdk.NotPacked >= 4.0.0 that Im not able to resolve.

Error from a new project when trying to install after installed SwedbankPay.Sdk 4.0.0

Severity Code Description Project File Line Suppression State
Error NU1101 Unable to find package SwedbankPay.Sdk.NotPacked. No packages exist with this id in source(s): C:\Program Files\dotnet\library-packs, Microsoft Visual Studio Offline Packages, nuget.org TestSdk C:\GIT\Dev\TestSdk\TestSdk.csproj 1

Hi
We are trying to add the possibility of recurring payments but are not successful with today's sdk.

According to the documentation, you should use this api
https://developer.swedbankpay.com/payment-instruments/card/features/optional/recur#verify

To get a RecurrenceToken.

swedbankPayClient.Payments.CardPayments.Create
This only has the following interface:

Task Create(CardPaymentRequest paymentRequest, PaymentExpand paymentExpand = PaymentExpand.None);

    Task<ICardPaymentResponse> Get(Uri id, PaymentExpand paymentExpand = PaymentExpand.None);

    Task<ICardPaymentRecurResponse> Create(CardPaymentRecurRequest paymentRequest, PaymentExpand paymentExpand = PaymentExpand.All);

    Task<ICardPaymentVerifyResponse> Create(CardPaymentVerifyRequest paymentRequest, PaymentExpand paymentExpand = PaymentExpand.All);

Where it is then thought that we should use the last one with CardPaymentVerifyRequest

But this cannot be used as it lacks the flag to request token for recurring payment.

cardRequest.Payment.GenerateRecurrenceToken = true;

and if you ignore this and try with this anyway, you will get a crash in the function
public CardPaymentVerifyRequestDetailsDto(CardPaymentVerifyRequestDetails payment)

on the line
Amount = payment.Amount.InLowestMonetaryUnit;
then amount is always null as it has no set.

Thankful for any hint if we are using the wrong api.
//Regards Joacim

Hi. I can not find the RestrictedToInstruments property of OrderItem (Create Payment Order Request). How can I specify instruments in my request?

I have been testing the SDK and have following feedback and suggestion for improvements:

1. The current code does not allow us to deliberately re-use code for Payments instruments. An example is PaymentsResource.cs where the methods for getting and creating payments are close to identical. This should be abstracted so there is only need for getpayment and createpayment.
2. In src/SwedbankPay.Sdk/SwedbankPayHttpClient.cs:
   The SwedbankPayHttpClient class is made internal although GET, POST, and PATCH methods could be useful other places.
3. The readme.md does not provide necessary information for a basic implementation. It would be helpful for the users to have a beginner's manual in order to get started with an implementation.

This issue is for discussion of an operations design, so that we retain the functionality provided by our APIs with a list of dynamically available operations, so the state management of operation availability is preserved by the server and not moved up into the client.

Hi!
When will you add support for Checkout V3?

The CustomDateTimeConverter reads the string value with DateTime.Parse which uses the current culture.
When converters returns the DateTime it sets the kind to Utc, which is incorrect.

Currently I get errors because the api returns new types of PriceType.
The SDK should/must support having unknown enums so when types are added to the api the SDK does not break down.