Direct URL Access

Direct URL Access allows a customer to load a Hosted Payment Form without your server first calling the instance initialization endpoint.

Prerequisite

The saved form must have:

{
  "directUrlAccess": "ENABLED"
}

New forms are intended to default to DISABLED. When disabled, a direct request must be rejected with not-found behavior so the page does not reveal whether a form exists.

Enable Direct URL Access in PayConex

1. Go to Tools -> Hosted Payment Forms
2. Create a new form or edit an existing form.
3. Go to the access and security settings.
4. Enable Allow direct access.
5. Review the security warning.
6. Save the form.
7. Copy the form URL from the success view or form management experience.

Preview is intended to be available only when Direct URL Access is enabled.

Obtain and use the URL

Use the url returned with the form configuration.

The production example of a checkout URL is the following:

https://secure.paymentpage.com/c_5249941f13564471b3be9f96a6d532c1

Treat this as an example, not a template. Do not create URLs by concatenating a hostname and ID. 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.

You can place the returned URL in a merchant-controlled web page, email, QR code, or printed material. Test the exact link before distributing it.

Supported input behavior

Direct access renders the saved form configuration. The customer can provide the amount and fields exposed by that configuration.

The V4 API does not support query-string parameters per customer for prefilled customer data, references, amount overrides, confirmation URLs, or custom-field values. Do not add these values to the direct URL. If the checkout must carry order-specific data, make use of the Payment Form Instance and Rendering.

Direct-access lifecycle and Result Processing

In comparison with Payment Form Instance and Rendering, Direct Access avoids explicit initialization, so covering how a merchant can handle a resulting payment, if need be, is important.

The supported ways to look up resulting payments are:

• Via a webhook subscription; or
• By redirecting a customer to the merchant confirmation URL that handles the payment metadata
  • For the full guide on this, refer to

Security considerations

A reusable URL can be forwarded or discovered and can receive bot or card-testing traffic. PayConex product requirements apply reCAPTCHA before payment submission, with an invisible v3 check and a v2 challenge when step-up is needed. Existing account-level IP-blocking and payment-page auto-lock controls can also affect the page.

Merchants should:

• Enable Direct URL Access only for forms that need a reusable link;
• Avoid placing confidential data in the URL;
• Use amount minimums and maximums appropriate to the use case;
• Monitor transactions and declines;
• Keep applicable account-level fraud controls enabled and maintained; and
• Pause or disable (even delete) the form if the URL is being abused.

Direct URL errors

Customers may see a safe error page when:

• The form ID is invalid or unknown;
• Direct URL Access is disabled;
• The form is paused, locked, or deleted;
• The account or form is otherwise unavailable; or
• Account-level security controls block the request.

Direct Access disabled is intentionally presented as 404 Not Found. Do not use different customer-facing behavior to test whether a form exists.

Direct Access compared with an initialized URL

A direct URL identifies a reusable saved configuration. An initialized URL identifies a time-limited single-payment instance. Do not substitute one type of identifier for the other.

If the url that starts with the c_ prefix, the checkout URL is direct access URL: e.g. https://checkout-cert.paymentpage.com/c_8fb90eaace6d49f7bd43ffde49a375ac.

If the url that starts with the i_ prefix, the checkout URL is an URL initialized from a payment configuration: e.g. https://checkout-cert.paymentpage.com/i_7aa95446599d4869971f80fec201f5fb.

If you need a merchant reference, prefilled fields, a defined instance timeout, or authenticated instance result retrieval, initialize an instance instead.

Resource identifiers difference:

• hpf_e43079f5d7f8408292363cc875d61dba
  • This resource identifier represents a hosted payment form configuration
• hpfi_84f5163f6a4e48dcbaf52de4a7c21060
  • This resource identifier represents a hosted payment form instance derived from a payment (form) configuration