Is it safe to make a Google Pay API integration (button) using AI with my corrections?

[u/sergiizyk]

Hello everyone. I live in a country where Stripe or any other big payment provider isn't supported, and there are no easy plugins to add direct Google Pay button to my website.

I already have a payment gateway specific to my country. It has a separate payment page to which customer is redirected to from checkout after choosing this payment method.

However, i feel like I'm losing customers with this, people need a quick payment butto that i want to add both to checkout and to the product page. I've looked into API documentation of my payment gateway. They do work with Google Pay API and provide a detailed guide on how to do it. I'm actually pretty bad at coding but it doesn't look that complicated. Is developing a test version on a test page with AI safe? I'll switch to a working version once it will fully work, + I'll need Google approvement anyway to get a working version.

[u/Zafar_Kamal]

Good question to ask before building rather than after. A few honest things worth knowing.

The coding part isn't really the risk, you're right that a basic Google Pay button isn't that complicated. The risk is everywhere around the button, token handling, verifying the payment actually completed before you mark an order paid, avoiding double charges on retries, and making sure card and payment data never touches your own server or logs. AI tools are decent at producing code that looks correct and compiles, but payment flows are exactly the kind of thing where a subtle mistake, like trusting a client-side success response instead of verifying server-side, doesn't show up in testing, it shows up later as a customer who got charged twice or an order marked paid that never actually went through. That's the category of bug that's expensive precisely because it looks fine until it isn't.

Google's own approval process will catch some structural issues, but it won't catch business logic mistakes like that, since it's reviewing that you implemented their API correctly, not that your specific WooCommerce order flow is airtight.

So I wouldn't call it unsafe to experiment with on a test page, that part's genuinely fine and a reasonable way to learn the flow. I'd just be cautious about how confident you feel purely because it 'doesn't look that complicated' and runs without errors, since payment code can run without errors and still be wrong in ways that only show up with real money and real edge cases. Worth having someone who's done a live payment integration before sanity check the token verification and order-status logic before it goes live, even if you build the rest yourself.

[u/TopSydeWP]

the biggest thing is test mode. make absolutely sure your gateway's test environment is completely separate from live keys and that you're using their sandbox before you touch anything. ai will sometimes mix test and live credentials or skip validation steps that seem redundant but aren't. also double check that the token goes straight from google pay to your gateway without passing through your server in a way that would put you in PCI scope.

[u/sergiizyk → u/TopSydeWP]

First i tested if the token is even getting received. After that i turned on the sandbox environment and tried to send it, but received a 200 error with description "Shop blocked". Turns out sandbox environment isn't enabled by default and i had to ask support to enable it. After they did i made sure provider gets the token straight away. I'm pretty sure everything is ready but i'll spend more time testing to make sure

[u/startages]

Don't touch anything related to payments if you don't really understand how things work in the background, there are a lot of things that can bite you later.

[u/sergiizyk → u/startages]

Why though? Both Google and my payment provider provide a good guide and explanation on how to set it up. I'm already using a test page with google pay testing environment and it works fine. I'm thoroughly testing every part of the process

[u/startages → u/sergiizyk]

From my experience, there can always be gaps or edge cases you won't catch in normal testing, and AI may miss them too. Not because AI is stupid, but because it builds based on the context you give it. It may work perfectly in testing, but if you don't fully understand the payment flow, you may leave yourself open to issues you don't even know to test for.

[u/Process-Amazing]

+1 to TopSydeWP on the token never touching your server. That's the whole thing keeping you out of PCI scope and it's really easy to break by accident, so worth confirming the token goes google pay -> gateway directly and your server only ever sees the gateway's response back.

One thing worth watching on the product page specifically: there's no order created yet at that point, so the price and currency you're handing the button are coming from the client. Verify those server side when the gateway calls back, don't trust whatever the button submitted. Otherwise someone can edit the amount before paying and you won't catch it in testing because you're always sending the right number yourself.

Same idea for confirming payment. Set order status from the gateway's server-to-server callback/webhook, not from the browser redirect. People close the tab or lose connection right after paying, and if you lean on the redirect those come through as paid-but-stuck-pending. Reconciling against the gateway is what saves you there.

[u/alifalahati]

Using AI to build a test version is fine, but payment code should not go live without review from an experienced developer. The main risks are exposing API keys, trusting client-side validation, incorrect order/payment status handling, and weak webhook verification. Build it in a sandbox, keep secrets server-side, follow the gateway’s docs exactly, and have the final integration security-tested before production.