Hidden Assumptions in hyperswitch-prism

When an automation step is told to wait for both a page element and a URL change at the same time, both waits share the same countdown clock. If one of them takes a long time, there may not be enough time left for the other one to complete, causing the whole step to fail even though the page was perfectly fine — just slow.

What to do: If you see flaky failures on steps that wait for two things at once, split them into two separate steps, each with its own timeout, so slowness in one doesn't kill the other.

The Google Pay flow uses a saved login session so you don't have to sign in every time. Google expires these sessions after weeks or months without warning. When that happens, the tool just hangs waiting for a page element that will never appear, then fails with a timeout — giving no hint that you simply need to log in again.

What to do: If Google Pay token generation starts timing out unexpectedly, run the one-time login step again to refresh the saved session before investigating anything else.

The browser automation service needs a full copy of the Chrome browser installed in exactly the right place on the machine. The server starts up and says it's ready even if Chrome isn't there. The error only appears when the first actual job comes in, making it look like a request problem rather than a setup problem.

What to do: After deploying the browser automation service to any new machine or container, send one test request immediately at startup to confirm Chrome is installed and working before relying on it for real jobs.

Every time someone sends a job to the browser automation service, it starts a brand-new copy of Chrome just for that job and never reuses old ones. If many jobs arrive at once, you end up running many copies of Chrome simultaneously. Each copy uses hundreds of megabytes of memory, and there's no limit — the machine can simply run out of memory and crash.

What to do: If you expect more than a handful of simultaneous requests, put a concurrency limit (a queue or semaphore) in front of the browser engine so it only runs as many Chrome sessions as the host machine can comfortably support.

Automation scripts can save a value from one step (like a confirmation code) and use it in a later step. But there's no check that the step which saves the value actually runs before the step that tries to use it. If someone writes the steps in the wrong order, the later step gets an empty value or crashes — with an error message that doesn't explain the ordering problem.

What to do: When writing automation scripts that pass data between steps, always put the step that captures the value before any step that uses it, and test the script end-to-end at least once to catch ordering mistakes.

Some older payment processors send their responses in a text format that starts with a special marker in an older encoding. The system knows how to handle one kind of marker but not others. If a processor uses the older style, the response will fail to parse with an error message about bad data rather than 'wrong text encoding.'

What to do: If you add a legacy or XML-based processor and see mysterious parsing failures on otherwise valid-looking responses, check whether the processor is sending its data in an encoding other than UTF-8.

When a payment processor's firewall or content-delivery network blocks a request, it often replies with a web page saying 'access denied' instead of the expected payment response — but still uses the same HTTP success code. The system tries to interpret that web page as a payment response, fails, and tells you 'parsing failed' with no hint that the processor never even saw the request.

What to do: If you see repeated parsing errors that aren't obviously malformed data, log the raw response body temporarily to check whether you're receiving an HTML page rather than a real processor response.

The AI tool that writes new payment processor integrations for you assumes the AI service it uses is online, that the specific AI model it asks for still exists, and that your account can handle very large requests. None of this is checked before the job starts. If any of those things are wrong, you may wait a long time before getting an error, and any partial code that was generated might be written to disk in an incomplete state.

What to do: Before running the AI code-generation tool for the first time, verify your API key works and that the configured model name is correct by sending a small test request to the provider.