#demodian-connect

1 messages Β· Page 1 of 1 (latest)

upper shale
limber sorrel
#

Checking... (we had one event go fine, but this second one is on shakey ground and I'm not too comfortable with the situation)

#

Okay, so if I understand this correctly, when a customer buys a ticket, we take the ticket cost, add the appropriate taxes (based on the rate the promoter configures), add our percentage fee, and process the payment as a direct payment. We create the payment intent, set the promoter's account as the stripeAccount, add our fee as the application_fee_amount (which is part of the grand total [cost+taxes+appfee]). We get our fee. They get their amount (cost+taxes) minus the Stripe fee for the entire transaction.

#

And if there is a chargeback, it goes against the promoter's account, correct?

#

If there is a manual refund issued, we specify the amount sent to the promoter (for a partial refund), so we don't lose our application fee?

upper shale
#

replying to your three comments top down:

  • yep, sounds right!
  • yes
  • kind of depends. The owner of the connected account can issue the refund themselves without your involvement. Or you can call the API to issue the refund. If you do the latter you can choose to send them your fee back so they don't lose that(when they refund the customer gets the full amount, so the connected account can lose the Stripe fee and your fee on a net basis).
limber sorrel
#

for the last one, we consider our fee non-refundable. If the promoter issues the refund, what amount will they be able to refund? And we also have a refund system on our site, which does keep our fee and Stripe's fee out of the refund amount anyway.

upper shale
#

they refund the customer whatever was paid. So as mentioned that means they go negative overall since they don't get the Stripe payment fee, or your fee, back.

#

you probably want to talk to our support team about your business by the way so we can be sure we can support you

limber sorrel
#

ouch, guess that's something they have to live with. And yeah, I will have Michael reach out to the support team about any issues. I'm just in panic mode right now since we got the true picture of what is going on with this current promoter and her event. I'm not seeing it end well for her, but I have to worry more about covering our rears

#

I'm still in process of converting from the old Connect method with the modal popup to the new payment intents method, so I will use this as motivation to get that conversion completed quickly. We just got the Stripe Terminal working with our POS mode, so I'll have to get something similar figured out for the online purchase method.

#

I appreciate the helpful advice. I will see what I can do to get this implemented. Thanks

#

Just out of curiosity, is there a PHP example of connect-direct-charge-checkout that is just straight PHP with only the Stripe API? I don't use Slim or the others, so I will have to wade through the sample code.

#

Yeah, I prefer to build my own frameworks (I'm really old-school)

#

lol

upper shale
#

I don't think we have a complete sample like that no. We are/were trying to stop using Slim because yes, it tends to just cause confusion, but we have a lot of samples and not all of them get updated/re-written unfortunately.

You should be able to put it together using https://stripe.com/docs/connect/enable-payment-acceptance-guide?platform=web&elements-or-checkout=checkout#web-accept-payment and https://github.com/stripe-samples/checkout-one-time-payments which doesn't use Slim, it's for direct payments but you can bolt the Connect part on with reference to the docs

#

remember we don't intend for you to take the samples and run them in production, they are examples to show how the pieces fit together and you'd generally write your own integration by reading the docs and taking inspiration/patterns from the sample projects

limber sorrel
#

good deal. will look at that too! Yeah, all the code that I've used from samples tends to get a lot of shoving into our code base, once I understand what is going on with it. πŸ™‚

#

It's all of the pertinent details that I need.

limber sorrel
#

getting an error of
PHP Fatal error: Uncaught (Status 404) (Request req_toRj7O5RwrCSgV) Invalid checkout.session id: cs_test_a1N58VPMwwqkTZ7XK7dbEKGoxZj1onlzB2goO1etlUlGXiTkKrJ4KK7RaT\n thrown in /artfarm/inc/stripe-php-master/lib/Exception/ApiErrorException.php on line 38, referer: https://checkout.stripe.com/
when I try to do the following:
$session = json_encode(\Stripe\Checkout\Session::retrieve($_GET['session_id']), JSON_PRETTY_PRINT);

Stripe Checkout is a drop-in payments flow designed to drive conversion with just a few lines of code.

#

I have just updated to the latest SDK. I wasn't sure if that was an issue or not

random oracle
#

Looks like you're using the live API key to retrieve a Checkout Session creating in test mode

limber sorrel
#

moment...

#

yep, guess that's what i get for only 2 hours sleep... -_- Thanks

random oracle
#

πŸ˜† np!

limber sorrel
#

Is there a way to get the charge id from the checkout sessions?

#

a simple way... heh

random oracle
#

Yep. You can expand the related Payment Intent on the Checkout Session

limber sorrel
#

{
"id": "cs_test_a1N58VPMwwqkTZ7XK7dbEKGoxZj1onlzB2goO1etlUlGXiTkKrJ4KK7RaT",
"object": "checkout.session",
"after_expiration": null,
"allow_promotion_codes": null,
"amount_subtotal": 1000,
"amount_total": 1000,
"automatic_tax": {
"enabled": false,
"status": null
},
"billing_address_collection": null,
"cancel_url": "https://www.mycustom.events/tmp/canceled.php",
"client_reference_id": null,
"consent": null,
"consent_collection": null,
"currency": "usd",
"customer": "cus_KZOz1yGqAs8jAh",
"customer_details": {
"email": "demodian@bigorangedragon.com",
"phone": null,
"tax_exempt": "none",
"tax_ids": []
},
"customer_email": null,
"expires_at": 1636634629,
"livemode": false,
"locale": null,
"metadata": [],
"mode": "payment",
"payment_intent": "pi_3JuG9ZJ9eg6BbqhC1mOx1Z0A",
"payment_method_options": [],
"payment_method_types": [
"card"
],
"payment_status": "paid",
"phone_number_collection": {
"enabled": false
},
"recovered_from": null,
"setup_intent": null,
"shipping": null,
"shipping_address_collection": null,
"submit_type": null,
"subscription": null,
"success_url": "https://www.mycustom.events/tmp/success.php?session_id={CHECKOUT_SESSION_ID}",
"total_details": {
"amount_discount": 0,
"amount_shipping": 0,
"amount_tax": 0
},
"url": null
}
It is only showing the payment_intent as the ID, so I will have to look up the PI, correct?

random oracle
#

Are you using stripe-php?

limber sorrel
#

yes, I just used the following
$sessiondata = \Stripe\Checkout\Session::retrieve($_GET['session_id']);
$piid = $sessiondata['payment_intent'];
$paymentintent = \Stripe\PaymentIntent::retrieve($piid);
$chargeid = $paymentintent->charges->data[0]->id;

random oracle
#

Something like this:

Stripe\Checkout\Session::retrieve([
  'id' => 'cs_test_a1N58VPMwwqkTZ7XK7dbEKGoxZj1onlzB2goO1etlUlGXiTkKrJ4KK7RaT',
  'expand' => ['payment_intent'],
]);
#

Then the payment_intent will be the full object, not just the ID

limber sorrel
#

i can do that too... lol

random oracle
#

Saves an API request!

limber sorrel
#

Cool

#

That did the trick.

#

Thanks