Skip to main content
PaymentsAutomation

The API returned 200, but did the payment actually reach the database?

A 200 response says the request was accepted, not that the right row was written. Here is how a QA team checks the response and the data behind it in one test, and covers the integration risks around it.

Scenario: A QA team testing a payments API and its ledger

Problem

API tests checked status codes only; tokens were copied between requests by hand and the ledger row was checked separately in a SQL client.

Solution

Chained API requests, read-only database steps in the same test case, and generated integration and database cases for review.

Capabilities usedAPI automationDatabase checks in API suitesPer-environment connectionsIntegration and database test casesScheduled and CI-triggered runs

The problem

The payments team's API tests checked status codes and response bodies. Login tokens and new payment ids were copied from one request to the next by hand, whether the ledger row was correct was checked separately in a SQL client, and cases for timeouts, retries and duplicate requests were written only when someone found time.

  • Tokens and record ids were copied between requests by hand.
  • A 200 response passed even when the row behind it was wrong.
  • Database checks ran outside the test, so they left no record in the report.
  • Integration failure cases — timeouts, retries, duplicate requests — were under-covered.

The solution

The response and the data it should have written are checked in the same test case, by the same run.

  1. Chain requests without copy-paste

    API automation

    A step saves a value from its response — a JSON field, a header or the status code — and later steps use it as {{name}}, so a login token or a new payment's id flows on by itself. A value marked secret is used for real but shown as [REDACTED] in reports.

  2. Check the row in the same test

    Database checks in API suites

    Any API step can become a Database step that runs a read-only query against PostgreSQL, MySQL/MariaDB or MongoDB and checks the row count, whether a row exists, a cell's value or how long the query took. Verify in DB drafts the check for an API step — that the payment the call just created is in the ledger, say — for preview before it is added.

  3. Keep each environment's connection separate

    Per-environment connections

    Connections are saved per API environment with the password encrypted and only ever shown masked, so the same suite run against another environment uses that environment's connection of the same name.

  4. Write the integration and database cases

    Integration and database test cases

    Integration (SIT) generation writes cases that name both systems and the interface between them — contract, data flow, auth between services, downstream failure, ordering and idempotency, timeout and retry. Database generation reads the real schema of a chosen connection and writes cases that name real tables.

  5. Run it from the pipeline

    Scheduled and CI-triggered runs

    Suites run on a schedule or from the pipeline through the API and GitHub Actions, and results land in the same reports as UI and mobile runs.

What changes

  • A test case can check both the response and the row it was meant to write.
  • Tokens and ids flow between steps without anyone copying them.
  • Database evidence sits in the run report beside the API result it belongs to.
  • Idempotency, retry and timeout risks have test cases written for them.

Read more

Facing a problem like this?

Bring one of your own stories, suites or release questions to a demo and we will walk through it in the product with your QA team.

Book a demo Start free

More case studies

B2B SaaSScenario

A nightly suite that was red so often, its results stopped being read

Problem

The same few tests failed most nights, real regressions hid among them, and a screenshot showed that a step failed but not why.

Solution

Flaky tests separated from regressions, failures replayed with an AI root cause, and seeded defects that show what the suite really catches.

Read the case study