Security Considerations

Hosted Payment Form keeps payment entry and payment submission in the PayConex-hosted checkout. Your integration is still responsible for protecting credentials, customer context, redirect behavior, and the surrounding merchant experience.

Keep API credentials on the server

Never place PayConex API credentials in browser code, mobile application bundles, query strings, or the hosted-page URL. Perform configuration, initialization, authenticated result retrieval, and webhook administration from a trusted server.

Grant the narrowest scopes required for each task. Separate operational responsibilities when practical—for example, a checkout service might create and read instances without permission to delete configurations.

For the complete guide and requirements on API Authentication and best practices for certification and production environments, refer to API Authentication.

Use returned hosted URLs

Treat the url returned by PayConex as opaque:

• Do Not construct it from an ID;
• Do Not replace its hostname;
• Do Not add credentials or sensitive customer data;
• Do Not convert a direct configuration URL into an instance URL; and
• Do Not reuse an expired or completed initialized URL.

Environment-specific hostnames and route formats can differ.

If the URL is not registered by the PayConex gateway, it will be rejected via 404 not-found. PayConex can return a different host or route for the environment.

Protect instance identifiers

An instance ID is not a substitute for server authentication. Store it with the merchant's internal order or reference, avoid exposing it in logs or analytics beyond operational need, and use the account-scoped authenticated GET to retrieve results.

If your application lets an authenticated customer resume a checkout, verify that the customer is entitled to the associated order before returning the hosted URL.

Direct URL Access

Direct access creates a reusable public entry point. Enable it only when required and assume the URL can be forwarded or targeted by automated traffic.

Use Payment Form Instance and Rendering instead when checkout must be tied to a particular order, customer, reference, timeout, or per-checkout confirmation page. Pause (or even delete) a direct form if it is no longer needed or shows signs of abuse.

Sensitive payment data

Do not add card number, CVV, bank-account number, wallet token, or other sensitive payment data to:

• Initialization fields not specifically intended for it;
• Custom fields;
• Merchant URLs or redirect parameters;
• Logs, traces, analytics, or support notes; or
• Webhook processing logs.

Do not attempt to read or duplicate sensitive fields from an embedded hosted page. Merchants remain responsible for their PCI DSS obligations and should confirm scope with their compliance advisor.

Customer and custom data

Collect only data needed for payment or merchant operations. Treat customer, address, reference, and custom-field values according to your privacy, retention, and access-control policies.

Custom-field input is customer-controlled. Display it with output encoding and do not interpret it as HTML or executable content. Do not create a custom field for PAN, CVV, passwords, or security answers.

reCAPTCHA and abuse controls

The hosted runtime performs reCAPTCHA v3 on payment submission and can require a visible v2 challenge. Do not bypass, replay, or proxy verification tokens. The token and verification endpoints are part of the hosted runtime flow, not normal merchant-side integration.

The Hosted Payment Form also participates in existing account-level controls such as:

• Card Checking / IP Blocking rules can reject abusive traffic for their configured blocking period.
• Payment Page Auto-Lock rules can lock a form after configured decline thresholds or rates.

These are account settings, not per-form configuration fields. Review them before launching a reusable direct-access form and maintain a support process for legitimate customers who encounter a block.

Iframe integration

Product requirements support loading the returned hosted page in an iframe. When embedding:

• Host the parent page over HTTPS;
• Use only the returned PayConex URL;
• Provide a responsive container and accessible page title or surrounding context;
• Do not overlay controls that could mislead the customer;
• Test browser privacy settings and mobile layouts; and
• Do not assume Checkout Component SDK callbacks are available.

The Payment Form API does not define an allowed-parent-domain list or a merchant-facing postMessage contract. Confirm the production framing and completion-integration policy before depending on embedded navigation behavior.

Confirmation redirects

Use an HTTPS confirmationUrl on a domain you control. The redirected request should not, by itself, authorize fulfillment. Reconcile the authenticated instance or PayConex transaction before delivering goods, credit, or services.

Do not place untrusted customer input directly into a redirect destination. The current API accepts a configured URL, not a per-request arbitrary redirect (query) parameter or similar.

Webhook handling

Expose webhook endpoints only over HTTPS. Validate authenticity using current PayConex guidance, deduplicate by event ID, return 2xx promptly, and never treat an unverified payload as payment proof.