Skip to main content

Merchant Help


Affirm Merchant Help

POST vs. GET method

Related to: checkout_token 

The merchant object contains the user_confirmation_url and user_cancel_url, which represent the two possible outcomes of the checkout attempt. The user goes to the confirmation_url if the user is approved and confirms their loan. The user goes to the cancel_url in all other cases (voluntary cancel, credit decline, identity verification issue, etc.). 

"merchant": {
    "user_confirmation_url":    "",
    "user_cancel_url":          "",
    "user_confirmation_url_action": "POST", // or "GET"
    "name":          "External Company Name"
required url. URL that the customer is sent to if they successfully complete the Affirm checkout flow. 
A checkout_token will be sent to this URL in the POST request, and that checkout_token should be used to authorize the charge before the user is redirected to the order confirmation page.
Analytics tags are other query string parameters can be persisted here as well. Read more here.
required url. URL that the customer is sent to if the customer exits the Affirm checkout flow.
This is the same if the user voluntarily cancels or closes the window before completion, or if the user is denied. You should setup the cancel_url to be the checkout payment page, and you can also append analytics tags to the URL to help you identify who you may want to reach out to about alternative payment methods or reapplying. 
Analytics tags are other query string parameters can be persisted here as well. Read more here.
optional string. Accepted values are: 'GET', 'POST'. Defaults to 'POST'. Read more here.
optional string. If you have multiple sites operating under a single Affirm account, you can override the external company/brand name that the customer sees. This affects all references to your company name in the Affirm UI.

optional string
Values: 'POST', 'GET'

This value specifies the HTTP Method for when the customer is redirected to the the user_confirmation_url with their checkout token. By default, this is set to POST and the checkout token will appear in the request body. If set to GET, the checkout token will appear in the query string.  

There are some important distinctions when speaking about request methods and form data:

  1. POST requests can pass data in the query string or in the request body, while GET requests can only pass data in the query string. POST requests provide more ways to send data.
  2. Requests can pass data for several reasons: form information (checkout data), tracking (UTM parameters), queries (searches). Generally speaking, that data can be passed through either the body or the query string.
  3. POST method data that's sent in the request body will not appear in the location bar (URL) of the user's browser window. Data sent through the query string with either POST or GET request method will be visible in the URL.
  4. HTTP best practices dictate that POST requests should be used if the request will result in some change on the receiving end. GET requests should only be used if the form data (like a search query) is only used to retrieve data (it doesn't cause any changes, like an order being completed). 

So, the use of POST requests is usually due to a combination of best practices, security and aesthetics. However, GET requests will allow customers to refresh the user_confirmation_url without being asked to confirm their resubmission.