Duplicate jsonproperty "external_account" in StripeAccountSharedOptions

[phl3x0r]

jsonproperties "should" be unique to allow deserialization to StripeAccountCreateOptions and StripeAccountUpdateOptions which both inherit from StripeAccountSharedOptions.

Error when deserialization:
{"A member with the name 'external_account' already exists on 'Stripe.StripeAccountCreateOptions'. Use the JsonPropertyAttribute to specify another name."}

[jaymedavis]

is this feature needed anymore? the way it is currently setup makes it easy to provide a card or a bank accounts for users. I don't think I want to change this to a single source property. with the new StripeResponse, you can retrieve the full serialized value of what was received from Stripe.

[banderberg]

The properties with duplicate JsonProperty values are causing our Swagger UI to fail. Not sure if you're familiar with that product but it doesn't like this. I've posted to their GitHub forum but if you happen to know a resolution please let me know, thanks.

[jaymedavis]

yes, i've used swagger. can you link to your post?

I'm not sure the best way to handle this. At one time, I had source as one property where you could pass a token or details (StripeSourceOptions). This was causing a headache for stripe because users kept trying to use both. I'm open for ideas to help mitigate this.

[banderberg]

I had actually posted to the wrong github forum but have corrected that, here is my post:

domaindrivendev/Swashbuckle.WebApi#979

[jaymedavis]

I guess there isn't anything that can be done with swashbuckle. The fix in Stripe.net could be having a nested object for everything that has two properties - for instance - Source object > Token OR Details. If you could compile me a list of all the places swashbuckle fails, I can see what our options might be. However, if they are major changes that will make the library harder to use, I will probably lean towards not fixing this. I hope that is not the case. Per the swashbuckle developer's request, I would just close that issue and we'll see if we can get it working on this side. 👍

[AFallad]

Hello!
Are there plans to work on this? The underlying issue is that the Newtonsoft.Json library checks for dupes in
here and I couldnt find a way to override this.

The current workaround I'm using is ignoring the JsonProperty attribute, but it's not ideal.

public class StripeContractResolver : DefaultContractResolver
{
    protected override JsonProperty CreateProperty(MemberInfo member, MemberSerialization memberSerialization)
    {
        var property = base.CreateProperty(member, memberSerialization);
        property.PropertyName = property.UnderlyingName;
        return property;
    }
}

[ob-stripe]

The root cause of this issue is that the library uses Newtonsoft.Json's attributes on request parameter classes, but requests are encoded using application/x-www-form-urlencoded encoding, not JSON.

I don't think we will fix this issue, at least not in a way that will enable JSON serialization of request parameter classes. What we should probably do is stop using Newtonsoft.Json's JsonProperty attribute and define our own FormProperty attribute, and look for those in our encoding logic.

[ob-stripe]

Contrary to what I said in my previous comment, we've made changes to the library to allow serializing options classes. As of version 27.0.0, you should now be able to serialize any options class instance to JSON.