Installment Payment Customization | MasterData | Checkout

VTEX in your native language 🌎 Portuguese
, ,
1

Hi everyone,
Good evening.

We have a customization scenario and would like to know if anyone has done something similar where we can find a more reliable solution.

CONTEXT
There is a customization at one of our clients that was implemented by a previous agency. The customization is:

  1. Customers can only use the Crediário (installment credit) payment method if they are approved;
  2. The approval is set in MasterData as true;
  3. The customization is still on the old checkout version and a query is made to MD to check whether that email is set to true or false. Based on this, a hide or block custom is applied to the Crediário payment method.

Here’s a quick look at how it currently looks:

image
image1058×742 33.8 KB

However, as is evident, there can be inconsistencies since VTEX does not support inserting customizations into the checkout, and the biggest problem with this is that sooner or later some customers manage to complete a purchase without actually being approved in the Crediário spreadsheet.

We have implemented some workarounds to make the function run as fast as possible and return a more accurate result, but it’s still not 100%.

We’re thinking that some custom version of a backend app might solve this. Have any of you worked on something similar? Do you have any ideas for this scenario?

Another question: the order in which payment methods are displayed on the frontend is directly tied to when they were registered. So our thinking is that if the Crediário option were second-to-last instead of last, the customization might work better.

What do you think?

We look forward to your feedback.

Thank you,

Four2One Management

2

Hi @four2one team, how’s it going?

Thinking about it, it might work to create a new trade policy with a Conditional Rule so that this trade policy is applied only to the desired customer cluster.

Then configuring the payment condition to restrict the availability of the desired payment method to the newly created trade policy — tied to the desired cluster via special conditions.

But I think the most common approach ends up being to implement these customizations via Checkout UI Custom or by configuring it directly in the SmartCheckout template, which, as long as there are no errors, should always run. Only if there are script errors in the checkout would it potentially prevent it from working.

3

Hey @andremiani, all good with you?

Awesome. That does seem like a viable path, but it involves changes to the commercial policy, right? We believe that would actually be a bigger change to the client’s business rules. We’re trying to avoid that as much as possible.

What we’re really testing here is something related to the order of payment methods at checkout itself. Basically, we save another payment option so it appears before the installment credit option, and that way the function can complete the entire logic process.

So far, it’s the simplest and most straightforward alternative we’ve found. We’re testing it to see if it actually works.

But thanks for the suggestion.

Cheers.

4

Hmmm maybe I’m not fully understanding your scenario, but specifically about the order of payment options in the checkout, CSS would do the trick.

First by setting the parent element with the display attribute as flex and the flex-direction to the desired direction, column or row;

.payment-group .payment-group-list-btn {
    width: 100%;
    display: flex;
    flex-direction: column;
}

Then you’d just need to change the order attribute of the desired payment methods, for example:

#payment-group-creditCardPaymentGroup {
    order: 1;
}

#payment-group-bankInvoicePaymentGroup {
    order: 2;
}

But if the idea is to restrict a specific payment method to a specific audience, I believe the approach is the same one I had mentioned before.

5

Hey @andremiani, ah yes. True, thinking about another cluster version, maybe the policy makes more sense.

About the order change:
We actually used that version, forcing it in the code. But it probably wasn’t taking effect yet due to the backend loading itself.

What we noticed from changing the order is that it’s just a matter of saving the method in the admin itself. VTEX always shows the frontend first for whichever one was saved last in the admin. So that’s what we did.

We’ll monitor it for a few days to see if it has the expected effect.

If anything comes up, we’ll let you know here.

Cheers.

6

Hi everyone,

Just a heads-up that the procedure we described above is now working. No recurrences.

So, saving the payment method last does have an effect on the customization we’re using at checkout.

I’ll close the topic.

Best regards,

Four2One Team