#Dooing-Subscription

1 messages · Page 1 of 1 (latest)

shadow rivet
#

👋 happy to help

#

welcome back @pulsar nymph

#

confirm with PaymentIntent Secret from backend
this should be done in the front-end not the backend

#

are you using Stripe Elements?

pulsar nymph
#

3/ Client-side

#

this is client side

#

and I still have no idea what stripe elements is. I assume it is the stripe ui

shadow rivet
#

yes the confirmation happens on the client-side

pulsar nymph
#

we have our own UI

#

the question is still, how does the backend receive the info of the first payment card

shadow rivet
#

we have our own UI
are you going to handle PCI compliance?

shadow rivet
pulsar nymph
#

are you going to handle PCI compliance?

#

yes

#

As I wrote, the backend sends the secret key, the frontend confirms it

shadow rivet
pulsar nymph
#

so I just see two ways - either the frontend sends the stripe payment id to the backend, together with potentially more data, or the backend receives an event.. or maybe even both

shadow rivet
#

is there any specific reason why you're choosing to go with your own inputs if I may ask?

pulsar nymph
#

please, I am currently focused on the backend flow. THe frontend is handled later / by someone else.

#

I just need to know if I can expect data / which data from the frontend, or not

shadow rivet
pulsar nymph
#

or if I need to listen to an event, eg. for confirmation that 3D secure is done

shadow rivet
#

if you're building your own inputs you would have to handle all of the 3DS workflow as well

#

I strongly advise you to reconsider using your own inputs

#

If there's a real solid reason for this let's discuss it

pulsar nymph
#

I repeat. this is currently not state of the discussion.

#

I am not doing it and it is currently not done

#

I think you wrote me last time:

#

for later confirmation, wait for a invoice.paid event with a billing_reason subscription_create
Then, get the Subscription and check if it is active now really

#

So this is I think foor the 3D secure confirmation

#

the question is, is that also the time to add the credit card.. or can / should the frontend send at least the payment id eaerlier

#

this is my currently missing piece to finish up the backend part

#

then I can forward this to the frontend guy and he / they will handle the other part

shadow rivet
#

either Front-end confirmation or front-end tokenization/backend confirmation

shadow rivet
shadow rivet
#

it's really a full-stack integration and you need to choose an approach and stick with it

pulsar nymph
#

ok, to simplify communication with you. Lets assume I DO use payment elements thing stuff shoot

#

then what?

shadow rivet
#

then you just need to implement the webhooks

#

confirmation and 3DS will be handled by the frontend

pulsar nymph
#

yes it will

#

the question is still.

#

How do I get the credit card into my database

#

I assume the frontend will get a payment Id from stripe

#

so it could send that to the backend

shadow rivet
#

How do I get the credit card into my database
you don't

pulsar nymph
#

oh yes I do

shadow rivet
#

the Payment Element will handle tokenizing and sending the info to Stripe

pulsar nymph
#

I do need, as a MINIUM, the payment Id and the afingerprint

shadow rivet
#

you don't store anything in your database

pulsar nymph
#

oh yes, I do

#

because I want to know if a credit card exists or not

shadow rivet
#

you shouldn't that's what I'm trying to say

pulsar nymph
#

if a new one is added

#

I understand PCI compliance

#

thats why I store a minimum

shadow rivet
#

ok

pulsar nymph
#

but I know also I can store the payment id and the finger print

#

and AFAIK last 4 digits and expiry date, are also fine, even if not necessarily required

shadow rivet
#

in that case once the PaymentIntent is successful you will have access to those information directly on the created Payment Method

shadow rivet
pulsar nymph
#

but they allow me to show the customer their details without having to allways get it from stripe

shadow rivet
#

but you don't need to store them I mean, you have access to them on the Stripe Payment Method object

pulsar nymph
#

I know

#

but again. it means additional calls to stripe - for nothing really

#

so I would like to minimize that communication

#

so again. My question from Today at 12:13 PM.

  1. Will stripe send the payment id to the frontend after 3D secure and all payment handling in the frontend?
  2. Will stripe also send the last 4 digits, the fingerprint, the expiry date?
rustic venture
#

Hey, taking over here! Just catching up

#
  1. A limited Payment Intent object will returned following successful confirmation with Stripe.js yes.
  2. We don't return those fields in that response no, only the pm_xxx ID.
pulsar nymph
#

so ONLY the payment method id, or something else also, like the finger print?

rustic venture
pulsar nymph
#

ok. So I could, send to the backend this ID, then the backend could get the further details to store those details in the backend database... But then I would have to sync up the details with stripe, whenever they are changing... so in a way, I'd have a duplicated state that may be out of sync on my end.

#

right?

rustic venture
#

Basically, yep. We generally only recommend storing the pm_xxx for that reason and looking up additional data as required

#

Alternatively you could subscribe to related webhooks to update your records if a PM object is updated

pulsar nymph
#

And the alternative? I assume the credit card will eventually be added, and the subscription will be eventually be confirmed, and I listen

to the
invoice.paid event with a billing_reason subscription_create, so I can activate the subscription, business side, for the customer, on my end, right?

rustic venture
#

Generally that only happens if its automatically updated by the networks (i.e. card renewal)

pulsar nymph
#

Wel I see a number of reeasons - credit card to expire, fraud, new card added / deleted / updated in the stripe dashboard...

rustic venture
rustic venture
#

If the customer adds/deletes a card, then it'd be a new pm_xxx object

pulsar nymph
#

which is also an updat to his set of card

#

I am just saying - for getting card info, just in time, I would make a payments info call to stripe (I have the details)

#

and would alwyas get the most up to date info

#

there I could also get a list of fingerprints

#

and then when a new payment intend with a new finger print is send.. I would check if the card is existing, and reject it otherwise

#

(who will then delete this abandonded card that will not be confirmed??? Automatically after x hours.. or do I need to do this on my own?)

rustic venture
#

Then you will need to store that data and implement webhooks to manage your records and keep them in sync with Stripe

pulsar nymph
#

store which webhooks?

#

sorry - store which data?

#

I thought I will not store any payment data and just instead retrieve in just in time

rustic venture
#

The related PM data that you want to check, but not lookup at the API each time (fingerprint, last4)

pulsar nymph
#

thats what I initally asked for.. and Tarzan was driving me crazy for INSISTING not to store it (and not answering anything else). But now that you finally told me that I will just receive the payment id anyway... I would need an additional request to stripe anyway.. so now I am trying a different, a "lazy route" by - just in time - retrieving this info from stripe directly, without storing any of those details on my end at all.

rustic venture
#

That's the better approach!

#

The fingerprint and last4 fields are fine to store (they're not considered PAN data, otherwise we wouldn't expose them via the API)

pulsar nymph
#

and the card brand, and expiry date, AFAIK, too

#

?

rustic venture
#

Yup!

#

They're useful when displayed a list of saved cards to a customer, for example

pulsar nymph
#

What happens when a customer does never confirm the payment intent secret?
Will those garbage objects in stripe be cleaned up after a while? Do I need to clean them up myself?

rustic venture
#

I don't believe they're ever canceled, no

pulsar nymph
#
  1. What if a customer within 24 hours, but in a later session wants to confirm the payment intent secret...
    Should I store the same secret in my backend and return it again.. or, as I assume, just create a new one?
#
  1. And do I need to check if such a state exists in stripe, before I start creating a new subscription from scratch?
rustic venture
#

What if a customer within 24 hours, but in a later session wants to confirm the payment intent secret...
Should I store the same secret in my backend and return it again.. or, as I assume, just create a new one?
Either can work, depends on your integration. There's no harm in incomplete PIs

#

I guess in those instances the Payment Intent would be canceled

pulsar nymph
#

so I guess.. I could just also ignore the "hanging subscription".. and just create a new one of the same type?

#

then I would have another "garbage subscription in state expired".. but probably no big harm?

rustic venture
#

Well once 'expired' that's a terminal state so unrecoverable

#

So it depends on how quickly your customer returns to your site as to whether they can continue with the old subscription

pulsar nymph
#

but, I'd assume, just ignoring it, and starting over, would not hurt either

#

thar would suimplify the flow on my end

last smelt
#

up to what works best for you I suppose.