What to Check in Payment Code Your AI Assistant Wrote

When an AI assistant writes your payment code, check five things yourself: the amount is in dollars and not cents, every request is signed, the customer's own address is sent, the return page is not trusted as proof of payment, and the sandbox tests pass again after each change. These checks catch the most common integration mistakes.

• Amounts: dollars with decimals, such as 10.50.
• Signing: every request proves it comes from your shop.
• Return page: never treat it as proof of payment.

1. Is the amount in the right unit?

EPaySe expects dollars with decimals. A ten dollar fifty payment is sent as 10.50, not 1050. Some payment systems use cents, and an assistant that remembers those may send the wrong number. Look at how the code builds the amount and test with a small payment in the sandbox.

2. Is every request signed?

Each request to EPaySe must include a signature that proves it comes from your shop. The exact format matters, down to details such as how the web path is written. If the signature is wrong, EPaySe answers with an unauthorized error. The EPaySe guide for coding assistants spells out the format and includes working example code, so compare what the assistant wrote with it. See give Claude Code the EPaySe guide.

3. Does it send the customer's address, not your server's?

EPaySe asks for the customer's own network address in the payment details. Code written in a hurry sometimes sends the server's address instead, which can confuse fraud checks. Check that the real customer address is passed through. Also check that the other customer details EPaySe requires are all filled in.

4. Does it trust the page the customer returns to?

After paying, the customer is sent back to a page on your shop. That page is only a visit, not proof of payment. Code that marks the order paid when that page loads can be fooled, and it breaks if the customer closes the tab. The code should wait for EPaySe's confirmation message instead. See mark orders paid only after EPaySe confirms.

5. Does a repeated request create a second payment?

Clicking pay twice, or a slow network, can send the same request twice. EPaySe lets you attach a key to each logical operation so a repeat is recognised as the same one. Check that the code sends it, reuses it only when it retries the same operation, and does not record a repeated answer as a new payment. Our guide to idempotency keys explains it.

6. Do the tests still pass after changes?

Run the sandbox tests again after every change the assistant makes, not only the first time. See test your EPaySe integration in the sandbox.

Why check a few things instead of everything?

Reading every line is best, but these checks are the ones that fail most often and cost the most. If you only have ten minutes, start here.

EPaySe is an early-stage payment gateway, still in development. Read the documentation for the exact rules.

Key takeaways

• Check the amount unit, the signing, the customer address, the return page and repeats.
• Compare the assistant's code with EPaySe's guide.
• Re-run the sandbox tests after every change.
• This is general education, not legal or financial advice.

Questions? Contact the team.

FAQ

What is the most common mistake in AI-written payment code?

Small format errors, such as sending cents instead of dollars or building the request signature the wrong way.

How do I check the request signature?

Compare the assistant's code with the signing example in EPaySe's guide, and test in the sandbox, where a wrong signature is rejected.

Why shouldn't I trust the page a customer returns to?

It is only a visit. The customer can close the tab or open the page without paying, so use EPaySe's confirmation instead.

How do I stop a repeated request from charging twice?

Send an idempotency key for each operation and reuse it only when retrying that same operation.

How often should I re-run my tests?

After every change the assistant makes, not only the first time.