Editorial illustration.
Originally published 16 June 2023; rewritten and reviewed on 15 October 2026.
I encountered this problem while integrating a payment gateway: the application needed to process a user’s input first, then send the browser to the gateway with form data using POST. A server-side HTTP request could send the data, but it would not move the customer’s browser into the payment journey.
Separate the three operations
A server HTTP client talks to another server. A normal redirect tells the browser to navigate according to its status and method semantics. A form submission makes the browser send a defined body to the destination.
Where the provider’s integration contract requires a browser POST, render a controlled form after creating the local order:
<form method="post" action="https://payments.example.com/checkout">
<input type="hidden" name="orderReference" value="SERVER_GENERATED_REFERENCE">
<button type="submit">Continue to payment</button>
</form>
This is illustrative markup, not a real gateway endpoint or complete signed request. Generate the required fields and signature on the server using the merchant’s current specification.
Control the destination and encode values
Do not accept an arbitrary form action from the browser. Select the approved gateway destination from configuration, and encode values for their HTML context when rendering the form. Hidden inputs are visible and editable to the user, so the server must establish their integrity according to the provider’s protocol.
If automatic submission is used, preserve a clear fallback button and explain the transition. Avoid inline script patterns that conflict with the site’s security policy.
Verify the return separately
Reaching the provider does not complete the payment. Process its response through the verified, retry-safe server workflow before fulfilling the order.
The lesson from this integration was to name the actor explicitly: which server sends data, which browser moves and which component establishes the final payment state? Once those roles are clear, the correct handover becomes much easier to design.