sherrardb

i think that i'll address this when adding PaymentMethods/PaymentIntents, since i'm guessing that the mental context will be more conducive and the variety of different `payment_method_details` will be more apparent.

I don't think that we support the Connect API. i believe that this is my first time reading about it. i'll leave this open in case it is something i...

i know that this is a very old request, but i was just circling back to an internal ticket that depends on this and thought to check to see what...

in the interim, we can simply update all metadata to `Maybe[HashRef[Str]`

correction, the combinations for `post_customer()` are not 2 x 2 x 5 because some combinations are not valid from a logical standpoint, ie `Net::Stripe::Customer` and customer id are not a...

also worth noting, for optional arguments, there are cases that are not as clear cut as "are we creating or updating a customer?" for example, `post_charge()` works without passing a...

@yahermann, i may be missing something obvious here, but within the provided snippet, how would one "convert" the current Kavorka signatures into Moose type constraints?

@yahermann, indeed i was missing something obvious. after getting back to doing some coding, i see that the Moose type constraints are already in place, essentially mirroring the Kavorka signatures....

this turns out to be a bit of a mixed bag. for validation that applies across all instances of an object, `BUILD` is appropriate. but for conditions that are specific...