Pass in custom headers for stripe requests

[machinshin]

we use this library at my work (indeed 2 of my coworkers are maintainers), it'd be nice if stripe-erlang had feature parity with other stripe api implementations.

https://github.com/Crowdtilt/WebService-Stripe#headers

[mattsta]

That's a great idea.

Currently our API doesn't have a way to pass metadata for individual requests (which is a design flaw we need to fix eventually), so I'm not sure how we can add custom per-request headers in a nice way with the current design.

Would it make sense to also make these new headers global env vars (temporarily until we can refactor for better isolation) or do they need to be custom per-request? Depending on your application concurrency, you can set env vars before each request, but that's very hacky.

The current headers in question seem to be: Stripe-Version, Stripe-Account, Idempotency-Key. I can't find an authoritative source for these headers in the official Stripe docs (they only mention Idempotency-Key). Any other sources we could build around? Though, I guess just allowing arbitrary injection of headers is what you need anyway, so the specific field names shouldn't matter.

Longer-term, it would be nice to re-create our entire erlang API using maps for args (or at least an optional map argument as "Config" on each function) and we should also probably return the entire Stripe response as a map instead of static records. But, using map return values will remove all the nice type information we have for records.

[machinshin]

here is info on 'Stripe-Version' https://stripe.com/docs/api#versioning

I can't find any docs on Stripe-Account though :| I'll have to ask my coworker where it's documented, though i guess it's possible it's something undocumented cause we have some odd requirements for our payment processor.

I think they can be global env vars as a short-term fix. As far as using maps, i kind of agree with you that using maps can lose you type information, but there has been some discussion about dialyzer support for maps => http://erlang.org/pipermail/erlang-questions/2015-January/082419.html

I'd definitely want to help improve stripe-erlang where i can though, it'd make it easier to convince people at work to use erlang :) Do you have any suggestions on where to start?

[machinshin]

it does certainly exist though, here's PR for stripe-ruby where they merged it => https://github.com/stripe/stripe-ruby/pull/188

[mattsta]

Oh, I wasn't questioning if they exist, was just wondering what they were. :)

I'd definitely want to help improve stripe-erlang where i can though, it'd make it easier to convince people at work to use erlang :) Do you have any suggestions on where to start?

Thanks!

The biggest help would be continue finishing the entire API: every object type and field value and operation at https://stripe.com/docs/api — it's a lot of repetitive "setup+typetypetype+record+annotate" work.

The main priority of this project is processing payments since other operations aren't as time-sensitive and can be manually run through the Stripe dashboard (for small projects, at least). Everything else is secondary, but still important.

It would be nice to have support for everything else including refunds, discounts, coupons, better marketplace support, allowing multi-card support now that they've added it, etc. Basically, all the functions that would let you re-create the entire Stripe dashboard using only Erlang API calls.

Adding new API endpoints is mostly:

• read the Stripe API docs
• pick something to implement
  • new types require a new record in the header with type data
  • new types probably have multiple operations to perform against them too (basic CRUD stuff), so that'll require creating multiple functions+endpoints potentially
• figure out how to make a nice Erlang function to encapsulate behavior(s)
• bundle the arguments into a https call
  • there's an existing pattern in the code for URL construction
• add tests against it
  • typically 2 to 5 tests against each function: obvious success, obvious failure, maybe-success-but-with-error = error (overflow, bad params, etc), maybe-success-but-corrupted-data = error, etc.
• update README to mention new feature(s)

If there's any implementation confusion, it's simple to evaluate how the other Stripe clients implement calls to find appropriate usage too.

[machinshin]

@mattsta thanks for the details!, i'm a bit booked at work atm, but that looks like it'll be clearing up in the next few weeks, so i'll start scannig the code and making PRs!