DevelopmentPayment protectionDetails
- Revisions within the package are free.
- If you do not respond within 3 days of delivery, the work is accepted automatically.
The money is reserved when you pay and released only once you accept the work.

Example result
Test cases: sign-up, cart and checkout of a small online tea shop
Cases from the "Checkout" area (4 of 18)
| ID | Title | Steps | Test data | Expected result | Priority |
|---|---|---|---|---|---|
| CO-01 | Order with a card, standard delivery | 1. Add 2 teas to the cart. 2. Open the cart, press Checkout. 3. Fill in the address, choose standard delivery. 4. Pay with the test card. | Test card from the payment provider's sandbox | The order page shows the number; a confirmation email arrives within 5 minutes | High |
| CO-04 | Free delivery threshold | 1. Add teas for $39.90. 2. Open checkout. 3. Add one more tea. | Shop rule: free delivery from $40 | Delivery shows $4.90, then $0.00 after step 3 | High |
| CO-09 | Postcode left empty | 1. Fill in every field but the postcode. 2. Press Pay. | — | The form is not sent; the postcode field is marked with a clear message | Medium |
| CO-15 | Back button after paying | 1. Pay for an order. 2. Press the browser's Back button. | — | No second charge; the cart is empty | High |
Checklist: cart (part)
- The quantity can be changed with + and − and typed in
- Removing the last item shows an empty cart message
- The cart is kept after closing the tab and coming back
- Prices and the total match the product pages
Files: an Excel workbook with the cases, a Result column and the checklists, and a Word file with the test plan. We write the cases from the description and screenshots; the shop's own people run them.
Client: Leaf & Kettle, an online shop selling about 80 kinds of loose tea, on its own site. Task: cases the shop owner and an assistant can go through before each update. Standard package: 60 cases in up to 4 areas, checklists and a short test plan. Excerpt below.
The client and all details are made up.
About this service
In an app that moves money, a small fault becomes a complaint at best: a transfer shown twice after a retry, a limit that resets at the wrong hour, a fee shown on one screen and missing on the confirmation. We write test cases for the flows you describe: transfers between own accounts and to other people, payments by details or by template, confirmation with a code, limits and fees as your rules set them, currencies and rounding, statuses such as pending or declined, history, statements and notifications, and what happens on a lost connection or a second tap. Each case has steps, test data, the expected result and a priority. You get an Excel workbook; from Standard a Word test plan, and in Premium a regression checklist and a bug report template. We write; your people run them in a test environment. The cases do not check compliance and are not financial or legal advice.
What is included
- What you getAn Excel workbook with the flow cases: ID, flow, title, preconditions, steps, test data with made-up accounts and amounts on the edges of your limits, expected result, priority and a column for your result, plus a checklist per flow. From Standard, a Word test plan with devices, the test environment and what counts as done; in Premium, a full plan, a regression checklist for each release and a bug report template.
- TransfersOwn accounts, other people and templates
- Limits and feesAs your rules set them, at the edges
- ConfirmationsCodes, timeouts and repeated taps
- Statuses and historyPending, done, declined and returned
- FailuresLost connection, retries and double sends
How it works
- 1FlowsYou send the screens and your rules for limits and fees
- 2CasesWe write the cases, checklists and plan from your description
- 3DeliveryYou get the Excel workbook and the Word file on the order page
- 4Your runYour people run the cases in a test environment
What we need from you
The flows to cover, the account types and currencies, your rules for limits, fees, rounding and cut-off times as they are set in the product, how a payment is confirmed, the statuses a payment goes through, notifications, the platforms and versions and what broke before. Screenshots with made-up data, a feature list or requirements: up to 5 files as images, Word, Excel or PDF. Never send real account numbers, cards, logins, codes or client data.
We will ask you:
- Which money flows should be covered?
- What are your rules for limits and fees?
- How is a payment confirmed?
- What has broken before?
Compare packages
| Packages | Basic25 cases for one money flow$13 | Standard60 cases, up to 4 flows$31 | Premium120 cases, up to 8 flows$62 |
|---|---|---|---|
| Deadline | 1 day | 2 days | 4 days |
| Revisions | 1 | 2 | 3 |
| Test cases | 25 | 60 | 120 |
| Areas or features | 1 | up to 4 | up to 8 |
| Checklists | 1 | up to 4 | up to 8 |
| Test plan | No | short | full |
| Regression checklist and bug report template | No | No | Yes |
| Product | Transfers and payments | Transfers and payments | Transfers and payments |
| Order Basic | Order Standard | Order Premium |
Payment protection
You pay when you order, but the money is released only for accepted work.
- Fixed priceThe package price does not change after you pay.
- The money is reservedWhen you pay, the amount is only reserved. It is released to the service once you accept the work.
- Checked before deliveryEvery result goes through a quality check before it reaches you, and you see it on the order page before accepting it.
- Free revisionsAsk for changes within your brief as many times as the package allows.
- Acceptance after 3 daysIf within 3 days of delivery you neither accept the work nor ask for changes, it is accepted automatically. If you write in the order chat after delivery, the order waits; once we answer, we may start the 3 days again and will say so in the chat.
- Redo or a full refundIf the result does not match your brief and the revisions did not fix it, or the work takes more than twice its deadline, write in the order chat: we will redo the work or refund the payment in full.
Questions and answers
Will you test the app or make payments?
No. We write the cases and checklists; your people run them in a test environment. We never log in, move money or use your app.
Do the cases show that we meet banking rules?
No. We take your rules for limits, fees and checks as you give them and write cases that show whether the app follows them. Whether your rules meet the law or a regulator's requirements is for your compliance and legal advisers.
Is this a security test?
The cases include basic checks, such as a confirmation code not working twice. They are not a security audit or a penetration test.
Which data should we run the cases on?
On a test environment with made-up accounts and amounts. The cases never need real clients, cards or money.
Do test cases mean the product has no bugs?
No. They cover what you describe at the depth of your package; bugs outside the cases can remain, and the result depends on how carefully the cases are run.
Did not find your answer?


