BUYER CHECKLIST / ONLINE STORES
Ecommerce website checklist for a clear quotation.
Planning an online store for a Jamaican business? Decide what customers can buy, how payment is confirmed, where orders can go and who handles the work after checkout. Use these decisions to scope the build.
Use the ticks to review your requirements. They are not saved, do not certify payment compliance and do not approve a store for launch. Keep an owner and evidence record for each agreed requirement.
1. Choose an enquiry catalogue or a transactional store.
An enquiry catalogue lets a person assess an order or quotation. A transactional store accepts an order through a defined checkout and payment process. Choose the customer task before choosing features.
Start with a small representative product set for scoping: an ordinary item, a variation and an unavailable item if those cases apply. Product counts alone do not describe the work.
2. Confirm payment fit for your Jamaican business.
Ask the intended payment provider or acquirer to confirm eligibility for your business, settlement account and chosen checkout. Confirm the customer-facing currency separately from settlement currency, plus fees, refunds and onboarding dependencies.
A provider logo, an available plugin or a keyword search is not approval for your business. Use current written provider information before accepting an integration scope. Discuss payment-security responsibilities with your acquirer using the PCI merchant resources below; this guide is not a compliance assessment.
3. Write fulfilment, returns and total-price rules.
List where you deliver, collect or supply access, what you exclude and who confirms exceptions. A town name on a page does not establish a delivery service or an approved charge.
Agree the information shown before the order is placed: currency, approved charges, delivery or collection conditions and the return or cancellation process. Confirm applicable tax treatment with the business’s qualified adviser rather than guessing rates from a template.
4. Map what each order state means.
A checkout confirmation screen should not be the only evidence that an order is paid. Agree how the team checks payment and how uncertain outcomes are investigated before asking a customer to try again.
This is a requirements worksheet, not a claim that these capabilities are already included in a WDJ package. Choose the states and evidence appropriate to the proposed payment and fulfilment system.
| Scenario | Expected outcome to agree | Owner and evidence |
|---|---|---|
| Successful authorized test purchase | One order, correct totals and a confirmed payment state. | Store operator checks the order and provider test record. |
| Declined or interrupted payment | Clear recovery; no paid status without confirmation. | Payment owner checks the provider outcome and customer message. |
| Repeated submit or payment notification | No duplicate paid order or duplicate fulfilment. | Implementer demonstrates the agreed duplicate-handling check. |
| Cancellation or refund | Request and completed refund are distinguished. | Operator checks the order history and provider confirmation. |
5. Agree a realistic store test plan.
Use the payment provider’s approved test environment where available. A test plan must be agreed before transactions, customer messages or provider changes are performed. Any required live transaction needs separate authorization.
Exercise the whole journey on a phone and desktop: product choice, cart changes, totals, payment outcome and operator follow-up. Keep quality-assurance checks orders separate from genuine orders and business results.
6. Scope handover and ongoing ownership.
Agree who controls the domain, store, payment account, source and external services. Identify who updates prices, investigates payment issues, processes orders and approves access. Include a recovery check appropriate to the stored order data.
Bring your product examples, payment-provider questions and fulfilment rules to the quotation. Platform selection, integrations, price, timing, taxes and payment terms are assessed and agreed in writing before work begins.
What security work belongs in an ecommerce quotation?
Ask who maintains the store platform and integrations, who can access orders and customer information, and how failed or duplicate payment notifications will be reconciled. Confirm recovery and update responsibilities before accepting orders. A payment gateway and an HTTPS connection do not remove these responsibilities. Gateway availability, security assessment and any integration work must be agreed for your actual platform; this planning checklist does not certify a store as secure.
Your questions, answered.
Does this checklist mean a particular payment gateway is supported?
No. The business, bank account, currencies, provider approval and proposed checkout must be assessed. A plugin or provider name alone does not establish compatibility or an included integration.
Can I begin with an enquiry catalogue instead of payments?
Describe that customer journey in the brief. A catalogue with a deliberate enquiry path may be a different scope from online checkout; fit, follow-up and responsibilities are agreed before work begins.
Do I need to send card details or customer orders to get a quote?
No. General product examples and requirements are enough to begin. Do not send payment information, passwords or customer records in the quotation request.
Does checking every item approve launch?
No. The checklist helps define and review requirements. Actual implementation, agreed test evidence, operational responsibilities and explicit owner launch approval are still needed.
Sources for further reading.
Use these primary resources alongside the guidance. Confirm current provider requirements for your own business.