Run an End-to-End Test Payment
This use case is not implemented yet.
Once your app is open, the builder takes over and makes a payment the way a customer would. It finds the button that starts a payment, waits for the Nuvei checkout screen to appear, fills in the card details, and then reads the outcome directly from the app's own records. It repeats this once for each payment method you have added. This is the step that proves the whole chain works together: your app, the Nuvei SDK, your backend, and the gateway itself.
-
A declined payment counts as a success - Reaching any answer from the gateway, approved or declined, proves every link in the chain works. The declined result may be a result of the test card.
-
Card details are handled by the tool, never by the AI - The AI is never given a card number. The builder types the card itself, using Nuvei's published test cards. They are stored in a fixed list built into the tool.
-
It reads your app's own card rules first - If you have chosen to block certain card brands, those brands are left out from the start rather than being tried and rejected, so the test reflects how your app is actually configured.
When a payment fails
If a payment does not go through, the AI is allowed one attempt to diagnose the problem, correct it, and try again. If the second attempt also fails, it stops. It then reports both attempts and what it changed between them, so you can see exactly what was tried.
This limit is deliberate and enforced by the tool itself. Repeated automatic retries tend to produce a long trail of changes and no clear answer. Stopping after one attempt keeps the result readable and leaves the decision with you. If you want it to keep going, you can tell it to continue.
Google Pay
Google Pay is the one payment method that cannot be tested automatically, because it cannot be tested on an emulator. An emulator has no Google Wallet and no card in it, so there is nothing to pay with. If you try, the builder tells you exactly that, and tells you what to do instead: connect a real device and run the test again.
Before Google Pay is tested, the builder stops and asks you to confirm that you have access to a real device with a Google account signed in and a card in its wallet. It also tells you to make sure it is a test card, not a real one - a Google Pay run can move real money. For that reason, the builder asks you directly, on every run. Your answer is never assumed and never remembered from last time, and the AI is not permitted to answer on your behalf. If you answer no, the test continues without Google Pay, and every other payment method is still tested as normal.
On a real device, the final step is yours. Google Pay asks for a fingerprint or PIN before it will approve a payment. That is Google's own security check, and nothing can complete it on your behalf. The builder handles everything leading up to it, then hands the last step to you.
When you test on a real device, the builder runs every other payment method first and leaves your app open on the phone. Google Pay is deliberately left until last, so by the time you are asked to do anything, everything else is already confirmed working. You are then told clearly what remains: tap the Google Pay screen by hand.
If both an emulator and a real device are available, you get to choose which one to test on before the testing process begins.