#skammerens-datter_api
1 messages ¡ Page 1 of 1 (latest)
đ 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/1265305337519411312
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- skammerens-datter_api, 59 minutes ago, 17 messages
- skammerens-datter_api, 3 hours ago, 11 messages
- skammerens-datter_api, 1 day ago, 34 messages
- skammerens-datter_api, 3 days ago, 24 messages
- skammerens-datter_api, 4 days ago, 35 messages
- skammerens-datter_api, 4 days ago, 13 messages
and 2 more
No, you can either make a manual API request using an HTTP request tool, or you need to update the SDK to a version that supports customer sessions
Its not the API version, its the SDK version, since support for this was only added after it was released recently
My API on Stripe Dashboard under "Developers" is from 2020 though
but, I'll update the SDK, if that is not pertinent
is there a way for me to be sure that there are no breaking changes in the SDK (php)?
the SDK I am using currently is stripe-php-7.87.0, and in the Github repo it states: You can continue to use the legacy integration patterns used prior to version 7.33.0. Review the migration guide for the backwards-compatible client/services pattern changes.
There likely are, which you can review in the changelog: https://github.com/stripe/stripe-php/blob/master/CHANGELOG.md#1390---2024-01-12
You're several major versions behind, so please review the breaking changes carefully
okay, I'll make it work without the customer session.
if I wish to add a payment method (card) to a customer, using Elements, do I need to supply a clientSecret on element? I ahve initialized it with mode setupand it generates the element. If I however set a clientSecret, the element is not rendered - however no errors in the console
hello! give me a second
no problem
so one thing to clarify
$stripe->customerSessions->create([ ...throws "Call to a member function create() on null"
your API version is not outdated.
Your SDK version is. Your SDK does not have a customerSessions class since it is so far behind that customerSessions didn't exist them. So if you want to use CustomerSessions, you'd have to upgrade your stripe-php SDK version. So that's one option. To confirm, is that something you are willing / unwilling to do? asking cause depending on how you are integrated, that might result in handling minimal or a lot of breaking changes
I'll stay with the current SDK and API, since we have a Stripe Connect integration implemented, that we do not have the time to redo currently.
My issue arose because I wanted to present our users with their existing payment method. We have a Subscription integration for our SaaS product.
Instead of using customer sessions, I'll fetch the existing payment method, and let our users remove that, or through the payment element replace it with a new card.
The issue that then occured was that if I supply a property of clientSecret of the setupIntent created on the backend, the payment element is not rendered. If I leave it out, it is rendered.
that we do not have the time to redo currently.
understandable!
I'll fetch the existing payment method, and let our users remove that, or through the payment element replace it with a new card.
gotcha, that makes sense
if I supply a property of clientSecret of the setupIntent created on the backend, the payment element is not rendered.
got it, so lets go down this path and figure this out
1/ what doc are you following, can you pls link?
2/ can you pls paste just your code for instantiating Payment Element?
3/ can you share the test mode clientSecret value?
- I am going through this: https://docs.stripe.com/payments/save-and-reuse?platform=web&ui=elements, since it was suggested to achieve the use case of updating a payment method.
- See below
seti_1PfjxIGppVLMkw06KEiZ82Ej_secret_QWnYUg0P7BStLdAkxBEUwtBLotv0ySZ
Payment Element code:
function renderPaymentEl() {
fetch("/ajax/subscription/AJAX_subscriptionUpdatePaymentMethod.php", {
method: "GET",
headers: {
"Content-Type": "application/json"
}
}).then(response => response.json()).then(data => {
var stripe = Stripe(data.apikey);
var stripeElements = stripe.elements({
mode: 'setup',
clientSecret: data.clientSecret,
paymentMethodTypes: ["card"],
locale: localizedStrings.locale,
fonts: [{
cssSrc: '/css/fonts.css',
}]
});
var paymentEl = stripeElements.create("payment", {
fields: {
billingDetails: {
address: 'never',
email: 'never',
name: 'never',
phone: 'never'
}
},
terms: {
card: 'never'
}
});
paymentEl.mount($(billingInfoEl)[0]);
paymentEl.on('change', function(event) {
if (event.complete) {
$(submitButton).prop('disabled', false);
submissionReadyBool = true;
}
else {
$(submitButton).prop('disabled', true);
submissionReadyBool = false;
}
});
});
}
1/ that is the correct guide
3/ SetupIntent looks fine, looking at your code
a/ can you remove everything from your stripe.elements() instantiation and just keep clientSecret: data.clientSecret param? and try that? and pls keep console logs open and let me know if anything new comes up there
the element is rendered, if only the clientSecret option is set
console logs no errors, when the rest are present and the element is not rendered
gotcha, so element is rendered, that's good.
Add back in all params and exclude mode: 'setup' and see if it renders still
it does not. I have tried several different configurations to see when it'd render. So far only with just the clientSecret
only message logged is:
Successfully preconnected to https://api.stripe.com/ and there are no pending XHR/Fetches
remove paymentMethodTypes as well as mode and try
doing that it does indeed load
gotcha so that means there's some combination of params on Payment Element that don't cause this to work. Our docs also don't use mode and paymentMethodTypes FWIW when instantiating Payment Element (locale and fonts should be fine) so just skip those.
I'll try to repro this and file with the team to better surface this as a warning or error (depending) in the console for why Payment Element doesn't render
okay, I assume I won't run into any issues not setting mode or paymentMethodTypes. It works, if the intent is a paymentIntent rather than setupIntent. There, the mode however is subscription rather than setup
not sure I understand, can you rephrase?
sorry, I only meant that if I set mode as subscription, it renders (paymentMethodTypes included), however there the clientSecret set is from a paymentIntent rather than setupIntent.
Just mentioned it in your efforts to debug/investigate with your team.
In my case, I'll continue without mode and paymentMethodTypes, since that does render per your help