Customizting the "Place order" button on the Block Checkout

[InpsydeNiklas]

To fully integrate our custom payment gateway with the WooCommerce Blocks Checkout page, we must be able to:

• detect the currently selected payment gateway & changes in the selection
• hide and replace the regular "Place order" button per gateway with a custom button/iframe
• trigger the form field validation for the custom "Place order" button/iframe (should be possible already using StoreApi)
• dynamically create gateways based payment provider API response (should not be an issue)
• integrate hosted fields (should not be an issue)

Our biggest challenge is customizing the "Place order" button per gateway.
The ability to modify this button may be needed for certain payment providers to work similarly to the already established solutions on the shortcode Checkout page.

[opr]

Hi @InpsydeNiklas thanks for the post, I have a few comments to make here:

detect the currently selected payment gateway & changes in the selection
It is possible to do this using the wc/store/payment data store.

const activePaymentMethod = useSelect( ( select ) => {
  return select( 'wc/store/payment').getActivePaymentMethod();
} );

I don't believe we emit any events when this changes, however checking the data store again after a change will yield the new gateway's name.

hide and replace the regular "Place order" button per gateway with a custom button/iframe

Is this because you want to change what happens on the onClick event of the button? What precisely is the flow when clicking the button? If we provided the ability to add/change class names, and to change the onClick handler, would that be enough or do you need more?

trigger the form field validation for the custom "Place order" button/iframe (should be possible already using StoreApi)

We have two levels of validation actually, one on the client, and one on the server. If you take a look at this data store documentation. Using hasErrors you can check whether any errors exist in the data store. This is the same check we do in the checkout before the shopper is allowed to proceed.

When posting to the server, the Store API checks on the expected vs. actual values of all fields and will not process the checkout if any are incorrect.

dynamically create gateways based payment provider API response (should not be an issue)

I don't fully understand this, could you share a little more information on this to help clarify?

integrate hosted fields (should not be an issue)

What are "hosted fields"? Are these fields specified by PayPal? Do they need to be sent in the Checkout post request too?

[InpsydeNiklas]

Hi @opr, thanks for your input. Here is a bit more context:

Our payment provider provides multiple different custom payment buttons in an iframe.

dynamically create gateways based payment provider API response (should not be an issue)

I don't fully understand this, could you share a little more information on this to help clarify?

Which payment buttons our provider returns depends on factors like geolocation. Buyers only get presented with the payment buttons that are relevant to them and the ones they are not eligible for will not be displayed.
Essentially, buyer A from country A may be presented with other payment options as buyer B from country B, without the merchant setting up any logic.
We can create individual payment gateways and display these buttons in their respective gateway description area:

But in that case, there would still be the regular "Place order" button which would not work for this gateway with the custom iframe button. We can make the "Place order" button trigger an error when clicked, but that's not an ideal user experience.
This means the regular "Place order" button should be hidden when our custom payment gateway is selected.
Ideally, we would like to be able to replace the regular "Place order" button with our custom iframe button:

But the render location of the custom iframe button is a secondary concern. The primary issue is removing the "Place order" button when it is not needed.

I don't believe we emit any events when this changes, however checking the data store again after a change will yield the new gateway's name.

If this event is relevant or not depends on how the "Place order" button would be handled. Detecting the gateway changes is part of the approach for the shortcode Checkout page, but if there was something more simple like a flag to hide the "Place order" button on the Block Checkout, then probably we would not need to detect changes in the selected gateway.

Is this because you want to change what happens on the onClick event of the button? What precisely is the flow when clicking the button? If we provided the ability to add/change class names, and to change the onClick handler, would that be enough or do you need more?

We must use these custom iframe buttons for the payment process, so ways to style the regular "Place order" button would not be sufficient. When the buyer clicks the custom iframe button, the form fields are validated and a popup window opens from where the payment process is completed. After confirming the payment in the popup window, the popup window closes, and the buyer is forwarded to the order-received page without any additional interaction on the Block Checkout page.

We have two levels of validation actually, one on the client, and one on the server. If you take a look at this data store documentation. Using hasErrors you can check whether any errors exist in the data store. This is the same check we do in the checkout before the shopper is allowed to proceed.

When posting to the server, the Store API checks on the expected vs. actual values of all fields and will not process the checkout if any are incorrect.

Thanks! As far as I can tell, triggering the validation with the custom iframe buttons should work fine but haven't tested it yet.

What are "hosted fields"? Are these fields specified by PayPal? Do they need to be sent in the Checkout post request too?

Hosted fields are essentially iframes rendered inside of regular form fields that can be styled with CSS. They are used by various payment providers (including PayPal) to provide merchants with more flexibility, e.g. to style their card fields to match their brand styling.
Inserting the fields (e.g. as credit card fields in the gateway description) should not be a problem as far as I can tell. But the confirmation of the hosted field payments may also be reliant on a custom "Place order" button and would not work with the regular one.

I hope this additional context helps!

[opr]

Hi thanks for the additional context, it's super helpful, and thanks for your patience waiting for my reply while I've been AFK. I am currently writing up a more technical discussion for this, but before I get too into it, I'm wondering why the following flow won't work for your use case?

1. User selects "Custom payment gateway"
2. Your plugin styles the existing "Place order button" with the correct branding for their location via some API we implement
3. Your payment method registers an observer for the onPaymentSetup event. This observer contains two things: i. Code to open a modal which contains all the logic you need to get the user authenticated/ready to pay. ii. A Promise that does not resolve until some condition is met, thereby suspending execution of the checkout flow.

const onPaymentSetupUnsubscribe = onPaymentSetup( async () => {
	let isLoginComplete = false;
	const setLoginComplete = () => {
		isLoginComplete = true;
	};
	window.customNamespace.setLoginComplete = setLoginComplete;
	await new Promise( ( resolve ) => {
		window.open(
			'/popup.html',
			'_blank',
			'width=600,height=600,popup=yes'
		);
		setInterval( () => {
			if ( isLoginComplete ) {
				resolve();
			}
		}, 1000 );
	} );
} );

Welcome to the popup login page
<script>
    const onLoginClick = () => {
        window.opener.setLoginComplete();
        window.close();
    }
</script>
<button onClick="onLoginClick()">Log in</button>

5. When the button in the modal is clicked, it triggers the callback on the opener window, which changes the isLoginComplete flag to true, causing the promise to resolve.

This is just example code and is super crude, but in theory would this allow you to achieve what you want? If not, what are the barriers here, and why would replacing the place order button allow you to overcome them?

[InpsydeNiklas]

Hi @opr

Thanks for your suggestions.

Your plugin styles the existing "Place order button" with the correct branding for their location via some API we implement

Unfortunately, this approach is not feasible because the custom iframe button's styling is controlled remotely by the payment provider. It's not just about styling the button for branding purposes either; the button dynamically updates its functionality based on the context for each website visitor individually. This button may display different labels or even additional menus depending on the payment methods the buyer has previously saved. Therefore, we have no choice but to use this specific custom iframe button instead of the regular "Place order" button. The custom iframe button can do everything the "Place order" button could, but not the other way around.

The payment process works seamlessly with the custom iframe button in the Express Checkout section at the top of the page or, as shown in the first example screenshot, from the gateway description area. However, in the latter case, the existing "Place order" button creates a confusing user experience because it is technically incapable of initiating the payment process for each unique situation.

The ideal solution would be to replace the "Place order" button with the custom iframe button, while the next best option would be to hide the regular button when our custom payment gateway is selected. Unfortunately, there doesn't seem to be a way to integrate the regular "Place order" button into the payment process without significantly compromising the user experience.

[mikejolley]

With these custom iframe buy buttons, how can you be sure the order is placed on the system before payment?

In the old checkout modal this seems like you'd have a payment step after the order is placed i.e. the button would be rephrased as "continue to payment" and a next step would have the iframe and payment controls. We don't have something like this in blocks now, but is it needed?

[InpsydeNiklas]

With these custom iframe buy buttons, how can you be sure the order is placed on the system before payment?

With our custom payment gateway, the payment process is initiated before the WooCommerce order is created. This differs from the traditional flow, where an order is created first and then the customer is redirected to the payment provider's website.
A regular payment method using traditional flows may function like this:

1. Creation of the WC order with the "Place order" button
2. Redirecting the customer to the payment provider's website
3. The customer completes the payment on the payment provider's website
4. The customer is then forwarded to the order-received page.

Here's how our process works on the shortcode Checkout page:

1. The customer initiates payment through the custom iframe button, opening a modal.
2. Once the customer confirms the payment in the modal, our plugin triggers the hidden "Place order" button.
3. This initiates the creation of the WooCommerce order and in process_payment, captures the payment from the payment provider.
4. The customer is then forwarded to the order-received page.

So first, the payment process is initiated, then the WooCommerce order is created, and then payment will be completed only when we capture it in process_payment.

We've successfully implemented this payment process with the custom iframe buttons on the Block Cart and Block Express Checkout sections, using onSubmit() and onPaymentSetup instead of triggering the "Place order" button."

[ralucaStan]

The payment process works seamlessly with the custom iframe button in the Express Checkout section at the top of the page or, as shown in the first example screenshot, from the gateway description area. However, in the latter case, the existing "Place order" button creates a confusing user experience because it is technically incapable of initiating the payment process for each unique situation.

We've successfully implemented this payment process with the custom iframe buttons on the Block Cart and Block Express Checkout sections, using onSubmit() and onPaymentSetup instead of triggering the "Place order" button."

@InpsydeNiklas is there anything blocking you from using the Express Payments area for your implementation?

[InpsydeNiklas]

Hi @ralucaStan

is there anything blocking you from using the Express Payments area for your implementation?

We are successfully utilizing the express payment area for the express checkout buttons in our current implementation.
There is nothing blocking us, we only have a few minor issues with correctly displaying all aspects of our custom buttons. For example, our custom button may provide a dropdown menu under certain circumstances. This dropdown menu rendering may be cut off and not display fully in the express payment areas.
But this issue is still under investigation as we haven't yet understood if we can fix it ourselves or if this requires the involvement of the Blocks team.

However, the utilization of the express payment area is separate from the payment gateway we are looking to implement additionally. The only thing that is currently blocking is in this regard is the ability to replace/hide the regular "Place order" button.

[opr]

Hi @InpsydeNiklas we're going to close this discussion and keep #9432 open to collect further feedback/updates, please post there if you have more to add. Thanks!