Charge on rejected accounts

[José Fernandes]

Hi guys,

I'm developing a payments solution based on Stripe connected accounts.

I've recently started to make some tests for edge scenarios and I ended up on some unexpected results.

In those tests I create random connected accounts with:

```

$account = \Stripe\Account::create(array(

    "managed" => true,

    "country" => "US",

    "email" => $email

));

```

So transfers schedules are manual on 2 days rolling

I create tokens for simulating credit cards:

```

$token = \Stripe\Token::create(array(

    "card" => array(

        "number" => "4242424242424242",

        "exp_month" => 1,

        "exp_year" => date('Y', strtotime('+1 year')),

        "cvc" => "000"

    )

));

``` 

And finally all charges use the destination parameter

```

$charge = \Stripe\Charge::create(array(

    "amount" => $amount*100,

    "currency" => "usd",

    "source" => $token->id,

    "description" => "Test charge--StripeChargeAccountWithoutPaymentInfo",

    "application_fee" => 100,

    "capture" => true,

    "destination" => $account->id

));

``` 

* Test scenario 1: Rejected account

In this scenario I wanted to see what happens when I create a charge over a rejected account.

I created the account, the normal way and then I reject the account with:

```            

$account->reject([

    "reason" => "fraud"

]);

```

Then I wait 60 seconds, giving time for Stripe to update any structure related to this account--this probably wasn't needed, still...

Then I refresh the account object and test for `charges_enabled` and `transfer_enabled`--both are false, as I expected.

Finally I try to charge for the connected account, and the charge is a success--which I did not expect.

After browsing in the dashboard I see I have a charge on the platform account, a transfer for the connected account and a payment on the connected account.

My big questions here are:

- why was this charge allowed?

- what happens to the charge in the long run, I mean will the charge ever be refunded to the client? When does this happen?

- can you guarantee that the connected account payment for this (and other charges) won't ever be transferred?

* Test scenario 2: Not verified account and a lot of charges

In this test I tried to create charges for an account that have accepted TOS and have an external account.

I create several "$token" and "$charge" objects for the "$account". The total amount was $25000

Every charge was a success--expected.

After browsing in the dashboard I see I have all charges on the platform account, all transfers for the connected account and all related payments on connected account--ok expected.

My questions:

- Does any of this amount will ever be transferred to this account external account if there's no action for identifying the account?

- Can you confirm the due_by parameter will be set? When it will be set?

* Test scenario 3: Past due account

In this test I've used an old connected account that have long be due.

I retrieve the account object and test for `charges_enabled` and `transfer_enabled`--both are false, as I expected.

Finally I try to charge for the connected account, and the charge is a success--which I did not expect.

My big questions here are:

- why was this charge allowed?

- what happens to the charge in the long run, I mean will the charge ever be refunded to the client? When does this happen?

- can you guarantee that the connected account payment for this (and other charges) won't ever be transferred?

----

Thank you guys!

José,

https://pt.linkedin.com/in/josemataf

[Fred Alger]

Hi José,

Great questions! Hopefully I can clarify what you're seeing here.

Rejecting an account—for fraud, or any other reason—only affects live mode charges on the account:

https://stripe.com/docs/api/#account_object-charges_enabled

Unfortunately this means there's a slight difference in behavior between charges created on a charges_disabled account on test mode vs live mode. In test mode, charges will always succeed regardless of that flag, whereas if that flag is set on the account you'll get this API error when creating a charge:

{

  "error": {

    "type": "invalid_request_error",

    "message": "This managed account cannot currently make live charges. The `verification.disabled_reason` property on the managed account will information about why this account is currently disabled. If you are a customer trying to make a purchase, please contact the owner of this site. Your transaction has not been processed."

  }

}

In live mode, when transfers_enabled = false, you will not be able to create transfers to the managed account's external bank account until the current verification stage is fulfilled.

In order to make it easier to test the verification flow, there are card numbers that trigger each verification stage and prompt for additional verification information. Depending on the stage, transfers_enabled and due_by will also be set. This document lays out the steps and guidelines for testing verification with your managed accounts:

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss+unsubscribe@lists.stripe.com.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at https://groups.google.com/a/lists.stripe.com/group/api-discuss/.

[Fred Alger]

Hi José,

Sorry for the early send! To continue:

Depending on the stage, transfers_enabled and due_by will also be set. This document lays out the steps and guidelines for testing verification with your managed accounts:

https://stripe.com/docs/connect/testing-verification

This recipe is also valuable for understanding how to handle the webhooks Stripe sends when more information is needed about a managed account:

https://stripe.com/docs/recipes/identity-verification-notifications-for-managed-accounts

Hope that clears things up! If you have any specific questions about how to implement this in your application, feel free to write into sup...@stripe.com, we're happy to help.

Best,

- Fred.

[José Fernandes]

Thanks Fred for your responses. This helped me understanding the results I've been getting and also gave me directions how to test further.

Could you pin point other flows that will differ between sandbox and live. This would be really useful for preventing misunderstandings or bad assumptions when developing using your APIs.

Thank you again!

José Fernandes

Sent from Polymail

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.