#mikael_best-practices

1 messages · Page 1 of 1 (latest)

lapis zephyrBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1294264523531751434

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

polar belfry
#

First support email:

We are currently integrating a subscription solution using Chargebee and Stripe as the payment gateway.

To the point: I'm looking to implement a UI that enables our users to create/remove/update payment methods connected to their account. And currently the payment methods is stored as Chargebee, but the card information is gathered and stored by Stripe using Card Elements and the linked to the Chargebee payment method. So, as far as I understand, that makes the creation of a payment method PCI compliant since sensitive card information does not go through our servers at all. All good so far.

Now to the next feature, which is to update information for a payment method. Chargebee as API endpoints that allow us to send BIN and expiry information to update a payment method. In other words: Name, address, zipcode, country etc and expiry date and year can be sent to their REST API from our server. Populating the edit form would require a REST call to your API to get the card information from you. Your documentation states that any information returned from your API is not applicable to PCI compliance and is safe to transfer/store. After updating the payment method at Chargebee, Chargebee would then sync the changes to Sripe automatically according to their documentation.
So the question then is: Is this process of fetching and transferring non-PAN card information back and forth between our integration and Chargebee and Stripe PCI compliant? And I mean PCI compliant the the way that would require the least amount of effort from us; SAQ-A as I understand it.

I realize that this question maybe should have primarily have gone to the Chargebee support, but I've yet to had a great experience with their support so I figured as this question is not service provider specific since it's related to PCI compliance, I would get a much better response from you.

fresh eagle
#

What is 'card data without PAN'?

polar belfry
#

Second email:

No, I'm talking about the scenario where the end user has logged into our account portal and chosen to update one of their existing payment methods that has previously been setup for future charges using a setup_intent from Stripe. This means that the billing information such as name, adress, zip code and city along with card expiry details are stored at Stripe but linked to a Chargebee customer.
So, when the user clicks on "Edit", we need to display a form in our account portal which would need to be pre-filled with billing information and expiry information (but not the card number). So in order to get this information to be able to render said form, a call to your Payment Method API to retrieve a specific payment method is required, and the information in the response is den used to pre-fill the form so the user can make adjustments accordingly.
Then: when the user clicks on "Save", the form is posted to our account portal backend which in turn makes a call the the specific update payment method endpoint available in the Chargebee API. The documentation for this endpoint specifically stipulates that the information will be automatically synced over to Stripe by the Chargebee backend.

That last sentence is what I meant when I said 'transferred back and forth between Chargebee and Stripe'.

It is the fact that the billing info along with exipry date for the customers card is touching our server before being passed along to Stripe and Chargebee that makes me uncertain about the PCI compliance. But I've read that the PCI compliance is only relevant when this information is sent alogn with the acutual card number, which in this case it is not.

fresh eagle
#

Please dont just dump long email threads in here

polar belfry
#

I'm just giving you conext, I've tried reaching out to your support with great detail that has taken me alot of effort to write. So I dont't want to waste more time having to write the same things again.

#

card data = billing information and expiry date, without the acutal card number

fresh eagle
#

Which API calls are you makinbg and which parameters are you passing?

#

Generally you'd be prohibited from manually sending any card data to the API yes unless PCI certified

polar belfry
#

Right, it's the "generaylly" I'm trying to remove here. I want to find a definitive answer to this. Some sources say unless you send the PAN you are find sending the other data, since the main infomration is missing.
Most sources say, "in most cases", "usually", "sometimes" sending just billing information and expiery date is considered sensitive data.
Who actually knows if it sensitive or not? 😛

fresh eagle
#

Well we block the direct API usage without proof of PCI compliance so I would guess that answers your question

polar belfry
#

The information I want to send is.
Name
Addres,
Expiery year, month
Aderess1
Address2
Zipcode
City
State

lapis zephyrBOT
polar belfry
#

And if the actual call is to Chargbee Update Payment Source which in turn will update the payment method at Stripe?

fresh eagle
#

If you can make those API calls then you're fine without PCI compliance. We block anything by default that requires PCI compliance

polar belfry
#

No, since I was first trying to find out which level of PCI compliance we would need for planned solution.

pure verge
#

hi! I'm taking over this thread.

polar belfry
#

We are trying to keep the requried level of PCI compliance level low, thus trying to find a solution that keeps it low befor trying to integrate it.
And trying to find answers regarding this is a slippery slope I've found out 😛

#

Hi! 🙂

fresh eagle
#

Try those API calls with test keys on a test mode object, the same PCI rules apply there too

polar belfry
#

OK, roger that.
But my question still stands. Does this still hold true if the API call first goes to Chargebees Payment Source update endpoint which then will sync the same changes from them to you?

#

I understand that If I were to make the call directly to Stripe I would be find.
But I'm trying to make this 100% clear, that even if the data were to be routed via Chargebee first, the process would still be considered PCI compliant, preferabbly SAQ-A.

pure verge
#

what "holds true"? if you are not touching the raw card numbers, then it should be PCI compliant. and to get definitive answers about PCI compliance, you should talk to a laywer.

polar belfry
#

Right, let's turn the question around then.
What is your recommended way of creating a solution to enable our customers to create and edit payment methods staying PCI compliant?

pure verge
#

The recommendation is to not touch the raw card numbers. So for example use Payment Links or Checkout Sessions or the Payment Element to accept a payment.

polar belfry
#

I think those soltuions are not relevant for since we are talking about off_session charges, subscriptions to be more specific. Or I'm wrong in that assumption?

#

*for us

pure verge
#

if you want to create a Subscription, then you should use Payment Links or Checkout Sessions or the Payment Element to collect the payment method of the Subscription. then all recurring charges will be handeled by Stripe automatically.

polar belfry
#

and when the card expires?

pure verge
polar belfry
#

Alright, let's say we would then want to check "Use your own custom link" since we would like to have full control of the UI. How would we gather the updated paymet source on that link?

pure verge
#

same answer as above: either Payment Links, Checkout Session, or the Payment Element. it could also be the Hosted Invoice Page.

#

or event the Customer Portal

#

it depends on the UI you want to show your users.

#

Probabbly Payment Element is the best solution, to directly collect a payment method to pay the existing open invoice.

polar belfry
#

To me all those solutions sound like they have to with initial charge, setting up subscription, or one-time charge. Not updating payment method for an existing ongoing subscription.
Can you point me to some documentation descrbing how to use those solutions along with an existing subscriptions?
And I have to make it clear that currently we are using Chargebee to handle the subscription logic and Stripe as a payment gateway only.

pure verge
#

and then set the new payment method as the default for the customer.

#

you would get the unpaid Invoice, find the PaymentIntent that's included in that invoice, and use that PaymentIntent with the Payment Element.
here's our doc on the Payment Element: https://docs.stripe.com/payments/accept-a-payment?platform=web&ui=elements the main difference for you is you don't have to create the PaymentIntent, only reuse the one in the existing unpaid Invoice

polar belfry
#

Right. I understand. Thanks for your input.