stripe connect support?

[machinshin]

https://stripe.com/docs/connect

So Stripe recently upgraded connect to be a proper marketplaces API (kickstarter, for instance, would be using a marketplace type system..

1) user goes to a KS campaign page. & input CC. invests in item, for let's say $50) 2) KS charges user $50 + KS-user-fees, sends $50 - $KS-organizer-fees and takes a cut on both ends)

@mattsta i don't know if you've looked into this, but I was wondering if it would be better to integrate that into this library, or... ?

[mattsta]

It's a good idea. Right now our stripe-erlang library only supports one private token per application, so implementing stripe connect (and all the refactoring it will require) can open up more possibilities.

We'd need to implement these for standalone:

• https://stripe.com/docs/connect/reference#post-token
  • note: the top section of that page would be 100% UI / application-facing, not part of our library. The user-facing application would be responsible for sending the user to Stripe, retrieving the response token in the code field in the redirect, then generating an access_token using the endpoint https://connect.stripe.com/oauth/token.
• https://stripe.com/docs/connect/authentication#authentication-via-the-stripe-account-header
  • this is basically your #10 too
• https://stripe.com/docs/connect/authentication#authentication-via-api-keys
  • this is what already do, but we are currently limited to one global auth key at a time, so it needs some refactoring.

...and these for managed:

• https://stripe.com/docs/connect/managed-accounts#creating-a-managed-account
• https://stripe.com/docs/connect/updating-accounts
• https://stripe.com/docs/connect/identity-verification
• https://stripe.com/docs/connect/bank-transfers

The managed flow is a lot more complex with more possible error scenarios (file uploads required?!), but that's the only route to go if we want a 100% custom-branded shop interface.

The best path forward will be to add new functions with a required state/config/parameter variable as the first argument. We can retain the old API, default all old functions to create private state using the single-env-var key, then call the new config-based functions.

I think the refactoring would look something like this:

% Generate a default config map (or record) with our global key.
default_config() -> #{secretKey => env(auth_token)}.

% Original function arity.  Move body of original to new config-accepting function.
% Now old function generates a default config and calls new config-accepting function.
charge_card(Amount, Currency, Card, Desc) ->
  charge_card(default_config(), Amount, Currency, Card, Desc).

% New function (with body of original function) taking a Config parameter.
charge_card(Config, Amount, Currency, Card, Desc) ->
  .
  .
  .
  request_charge(Config, Fields).

Beyond the request_charge call, Config must cascade down until it reaches the actual request sending function too (request_charge -> request -> request_run).

In stripe.erl, it'll require refactoring until line 318 (which involves adding a config parameter to ~20 functions and also duplicating those functions by creating parameter-free versions. It's a little wrapper-driven bloat, but it'll retain API compatibility for single-user situations.)

So, it's definitely possible, just slightly time consuming. I haven't looked into the testing endpoints for stripe connect yet, but if they exist we also need to add stripe connect testing of everything to the test suite as well.

[ihiasi]

Forked it, gonna take a stab at this. Stay tuned.

[ihiasi]

@mattsta : are you sure the refactoring you recommended is correct for managed accounts ? The secret key is always the same (it's your platform's secret key) but the only thing that's extra for managed accounts is the destination account (see for example here https://stripe.com/docs/recipes/on-demand-app how you process payments, you need to have a -d source={TOKEN} -d destination=acct_blabla). Lemme know if I'm missing something, please - thank you.