Organisation and trust

Online payments without collecting card details yourself

A processor-hosted checkout can reduce exposure to card data. Check the integration, payment confirmation and remaining responsibilities.

The CloudCity teamPublished 2 min read

Selling online does not require building a form that stores card numbers yourself. A processor can collect sensitive information in its own interface while your shop receives the information needed to understand the outcome. This reduces the surface you manage, but responsibility for the website, accounts and integration remains. Start by understanding where data travels and who confirms each stage.

Choose an appropriate integration

A processor-hosted payment page and components embedded in a shop do not necessarily have the same requirements. Follow the supplier’s documentation and discuss the applicable assessment with your bank or processor. A PCI logo on the supplier’s website does not automatically certify your business. Outsourcing can reduce your scope, while remaining obligations depend on the actual implementation.

Keep card data out of ordinary channels

Do not request full card numbers or security codes through contact forms, email, chat or support tickets. Do not copy them into troubleshooting notes or screenshots. Support staff can usually work with transaction references and limited information supplied by the processor. Define what happens if a customer accidentally sends sensitive data so that it is not automatically redistributed among colleagues.

Separate returning to the site from payment confirmation

Reaching a success page does not by itself prove that money was collected. The integration must verify results through the processor’s documented mechanism, including the authenticity of notifications. An order may remain pending temporarily. Explain that state and avoid fulfilling orders based on a URL or browser message the customer can modify.

Prepare for errors and repeated attempts

Use the dedicated test environment to check declined payments, cancellations, delayed confirmation and returning after closing the window. Verify whether repeated clicks create one operation or duplicates. Do not arbitrarily label an uncertain payment as failed because a page timed out. Customers need the actual status and guidance on whether to wait, retry or contact support.

Protect the rest of the shop too

An attacker modifying checkout can change the payment destination even when the processor is secure. Update the platform and plugins, limit administrator access and protect the processor account with additional authentication. Review users, integrations and notifications. Keep secret keys on the server with restricted access, and use separate test credentials. A test environment must not accidentally connect to real payments.

Sources and further reading

A CloudCity editorial guide informed by the documentation below. Check the official source for rules and procedures that may change.

Back to the blog