Salla checkout testing should establish what happens when the journey fails, not merely demonstrate one successful purchase. Request a matrix connecting basket, address and payment conditions with expected customer-facing, order-management and notification outcomes. This is transaction acceptance, before conversion data is used to judge marketing performance.
Functional testing asks whether an approved rule works. Conversion investigation asks whether the offer and experience persuade visitors. Make transaction acceptance a separate delivery condition in a Salla store launch and rebuild scope, rather than folding it into visual approval or advertising launch.
Fix the test configuration first
Record the plan, theme, apps, payment methods, carriers and price settings used during testing. Provider logos are not evidence of activation. Salla's guide identifies payment settings and activation routes; confirm the actual merchant and provider state. Salla payment-method setup.
Approve test products, prices, addresses and accounts, and identify who prevents accidental fulfilment. Use a provider-supported sandbox or permitted test method. Where a real payment is necessary, obtain prior authorisation, amount limits, fee expectations and an agreed cancellation or refund procedure. Store access is not unrestricted authority to transact.
Record the configuration version or date with the evidence. If the merchant changes shipping rules during testing, earlier results may no longer describe the current store. Keep the change visible and decide which cases need to run again.
Derive scenarios from business rules
| Scenario | Customer-side check | Merchant-side check |
|---|---|---|
| Successful order | Correct item, amount and confirmation | Matching record and approved state |
| Unsupported destination | Clear explanation without a false delivery promise | No incorrect fulfilment commitment |
| Unavailable option | Behaviour matches the stock policy | No assignment of nonexistent stock |
| Incomplete payment | Understandable status and next step | Not treated as paid without evidence |
| Repeated submission | A comprehensible outcome | No unintended duplicate execution |
| Approved cancellation | Clarity about completed and pending actions | Order, payment process and stock reconciled |
Agree expected outcomes before running the tests, with provider input where needed. Some configurations may create pending orders while others behave differently. Do not treat one assumed result as universal. The essential requirement is that operations cannot mistake an unresolved payment for a confirmed order.
Include shipping in the transaction
Test delivery, address and payment together. An option that works for one address may be unavailable elsewhere because of approved merchant or provider rules. Include an in-coverage and out-of-coverage address, plus relevant fee boundaries and exceptions.
Salla describes provider-dependent order-status and inventory functions in shipping settings. Verify the selected carrier rather than generalising across every shipping company. Salla shipping settings.
Check that operations receive variant details and any agreed gift message or order note. Payment success is not enough if the employee prepares the wrong colour because the selection is absent from their workflow. Do not issue a real shipping label or collection request without explicit approval.
Worked hypothetical example: a gift shop
This is an educational test scenario, not a customer case or performance result. A store sells a box in two colours, serves a defined area and offers optional wrapping. The team selects five core cases: an available purchase, an unavailable colour, an unsupported address, an incomplete payment through a permitted method, and repeated submission.
For the successful order, product, wrapping and shipping amounts are compared with the approved values. The unavailable-option case checks the agreed stock behaviour. The unsupported address must not receive a delivery promise the merchant cannot fulfil. The payment-failure case is traced from the customer's screen through the record the employee sees, rather than accepted on the basis of the error message alone.
If a repeated attempt produces two records, the tester does not delete one to tidy the result. They preserve identifiers, timestamps and states, then the authorised owner checks financial and operational effects before remediation. The issue may require configuration changes or provider follow-up rather than a cosmetic button adjustment.
For every case, record the cleanup action. Test transactions should not remain mixed with normal fulfilment work, but cleanup must not destroy the evidence needed to explain an unexpected result.
Require actionable test evidence
A software quality assurance report should contain the scenario identifier, relevant configuration, reproduction steps, expected and actual outcomes, evidence, severity and owner. Hide sensitive customer and payment data, retaining necessary verification evidence only in authorised locations.
Distinguish a blocking defect, a known platform constraint and a later enhancement. If a constraint undermines the advertised offer, it needs a commercial decision or delayed launch, not a quiet note at the end of the report. After a fix, rerun the original case and affected adjacent cases instead of accepting “resolved” as sufficient proof.
Acceptance should state what was not tested. An approved card-payment test does not establish the behaviour of every deferred-payment provider. A limited matrix can be responsible if its boundaries are explicit and aligned with the actual launch scope.
Move to conversion improvement after transaction integrity
Conversion rate optimisation can then examine friction and prioritise testable changes using available traffic and trustworthy measurement. Not every abandoned basket is a payment fault, and passing functional tests does not guarantee sales. The test programme establishes only that the agreed transaction scenarios work.
Preserve the important cases as a regression baseline when the theme, apps or shipping configuration changes. Launch evidence is not permanent proof for a changing store. Agree who repeats the checks and when; ongoing maintenance should not be assumed to be part of a bounded build project.
Frequently asked questions
Is one successful purchase enough?
Not when methods, addresses or variants have different rules. Use a risk-based matrix rather than repeatedly testing the easiest journey.
How can failed payment be tested safely?
Use the provider's permitted method and appropriate authorisation. Do not improvise random payment details or unapproved real transactions to force a failure.
Is every payment issue the developer's fault?
No. Activation, provider rules, configuration or connectivity may be involved. Evidence should identify the failure boundary and responsible follow-up before assigning a cause.
Does testing include refunds?
Only within an agreed scope, with an authorised procedure, owner and fee expectations. Do not assume coverage of every financial scenario or payment method.
A useful next step
Provide payment and shipping rules with representative products. Request an approved scenario matrix, acceptance criteria and explicit testing authority before transactions begin.
Sources
Reviewed 26 October 2026: Salla payment methods and shipping settings.