— 5 reading minutes
Tailor-made payment processes with Stripe
In the dynamic world of e-commerce , online payment platforms have become a fundamental pillar. Not only do they facilitate fast and secure transactions, but they have also transformed the shopping experience, making it more accessible and user-friendly. This evolution has been driven by the need to adapt to an increasingly globalized and digitalized market. In this context, Stripe is not just a tool, but an entire payment management ecosystem . Its flexibility and focus on user experience position it as a relevant player in the current landscape of online payment solutions. Stripe has the advantage of having some of the best developer documentation we've ever seen , and it also has a host of advanced payment products, such as Connect for creating platforms where we have to collect a portion of the payment on the platform and pay a commission to a supplier, for example, or the other way around, where the payment is made directly by the supplier and the platform takes a commission (which is how Uber and similar companies work).
Other platforms
Other platforms
There are other platforms, of course, not just Stripe, we in particular had used Adyen a lot years ago.
PayPal, for example, is widely recognized and accepted, especially for its ease of use and security, but in terms of development and the introduction of new features, it has become very outdated.
Square excels at its physical point-of-sale solutions, ideal for businesses that combine online and in-store sales.
Adyen, on the other hand, offers a global payment solution, appreciated for its ability to handle transactions across multiple markets and currencies, making it ideal for businesses with a strong international presence. Overall, it is the most similar to Stripe in terms of capabilities beyond a simple payment processor, but its documentation and developer friendliness are much better than Stripe's.
There are more, of course, but this isn't an article about comparing payment methods, but rather introducing some ways to customize your Stripe payment.
Although we can document the most common cases we encounter here, today we're explaining a case that isn't very well-detailed in the documentation and we haven't found many references to it on the web.
The method currently recommended by Stripe for entering a payment into a website, when you don't want to do it with any of the no-code options that Stripe itself provides (its checkout, for example), because they are Stripe URLs and we want to do something of our own, is to use a Payment Element with a Payment Intent or a Setup Intent.
Payment Intent vs Setup Intent
Payment Intent vs Setup Intent
When using Stripe, we clearly distinguish between Setup Intent and Payment Intent, two tools with specific purposes. Setup Intent is used to configure payment details, such as credit card details, for future charges. This tool is ideal for scenarios where the customer expects to make recurring payments or subscriptions. During this process, an immediate charge is not made, but rather, the groundwork is set for a smooth payment experience in future transactions.
Payment Intent, on the other hand, focuses on executing payments in the moment. This feature is crucial for one-time transactions or instant purchases. In addition to immediate payment processing, Payment Intent offers the ability to save card information for future payments using the "setup_future_usage" parameter set to "off_session". This is especially useful for businesses looking to balance immediate transactions with the ability to retain customers for future purchases.
Beyond these basic differences, it's important to consider the workflow of each. For example, Setup Intent requires an initial interaction with the customer to obtain their consent and securely store their payment details. This aligns with data security regulations and PCI Compliance, ensuring that customer information is handled securely and confidentially.
In contrast, Payment Intent can be used in a more dynamic and straightforward environment. For example, in a traditional e-commerce store where the customer selects products and proceeds to immediate payment. Here, simplicity and speed are key, and Payment Intent allows for a seamless transaction without additional steps to set up future payments.
Payment Element by default
Payment Element by default
What we wanted to talk about occurs when using the Payment Element with its default configuration, in Spain something like this:
The tabs above are configurable based on the payment methods we have enabled and the type of payment we are going to make (we can make an intent in subscription mode, and we would not have available payment methods that do not work for subscriptions, for example).
In the documentation There's quite a bit of detail on how to change the look, especially how you can change the payment methods from tabs to accordion, and then aesthetic themes to adapt it to the page you're going to use it on.
Customize Element and remove country
Customize Element and remove country
The problem arises when, in Spain, no one generally asks for the country in the card field when making payments. This is especially true because it's a field that's often requested at another point in the e-commerce process, either because you've registered the user or because you're about to send them a shipment. In Stripe's case, this field is part of an object called billing_details , which is similar to the billing details.
const elements = stripe.elements(options);
const optionsPayment = {
defaultValues: {
billingDetails: {
address: {
country: 'ES'
}
}
},
fields: {
billingDetails: {
address: {
country: 'never',
postalCode: 'auto'
}
}
},
layout: {
type: 'accordion', // or tabs
defaultCollapsed: true,
radios: false
},
};
// Create and mount the Payment Element
const paymentElement = elements.create('payment', optionsPayment);
paymentElement.mount('#payment-element');Here we create some options for the PaymentElement in which we define that the country never has to be requested and that the postal code will be automatic.
In this case, too, there are options to display payment methods in an accordion.
Once this is done, when confirming the payment, you will need to enter the country (in this case, we are always entering Spain, but we could read it from another user field, such as the shipping field).
If you do not enter the country or do not have the postal code as automatic, you may receive an error:
Uncaught (in promise) IntegrationError:
You specified "never" for fields.billing_details.address.country
when creating the payment Element, but did not pass
confirmParams.payment_method_data.billing_details.address.country when calling
stripe.confirmPayment().
If you opt out of collecting data via the payment Element using the fields option,
the data must be passed in when calling stripe.confirmPayment()Which basically means that we've told you not to ask for the country or postal code, because we already had them from somewhere else, but we're not providing them in the payment confirmation, and it's necessary to do so, as shown below.
const {error} = await stripe.confirmPayment({
elements,
clientSecret,
confirmParams: {
return_url: URLTORETURN,
payment_method_data: {
billing_details: {
address: {
country: 'ES',
}
}
},
},
});