Checkout and Order Page URL Format Update Guide
The URL format for checkout pages and order status pages is being updated: the store ID (storeId) segment will be removed from the URL path, giving the checkout and ordering flow its own independent resource path instead of sharing resources with other storefront pages. This reduces the impact on checkout when traffic spikes during major promotions or when other storefront pages experience issues.
SHOPLINE will fully switch over the checkout and order page URLs for all stores on September 19, 2026, after which the URL format cannot be reverted to the previous version. Most stores don't need to take any action, only if your custom code apps, theme templates, apps, 301 redirects, Open APIs, or third-party systems parse or depend on the old URL path should you or your service provider refer to this guide to complete the technical adaptation.
| Important: Normal customer access, checkout, and page navigation are not affected. Links in the old format will automatically redirect to the new URL, you don't need to manually update any links you've already sent. |
1. Key Benefits of the URL Format Update
This checkout link update gives the checkout and order pages a more stable, dedicated resource path, isolated from the traffic and incidents of regular storefront pages. Even during traffic spikes from major promotions or when other storefront pages experience issues, the checkout page keeps its own reliability guarantees, helping buyers complete payment more smoothly and reducing the risk of interrupted or lost orders. At the same time, historical links continue to work through automatic redirects, so marketing emails, cart-recovery emails, and order links you've already sent don't need to be reissued right away.
2. Impact of the Format Update
This update applies to the checkout page and order status page URLs for all stores. The store ID segment that was previously part of the URL will be removed from the path, leaving only the information needed for checkout or order lookup. For example, the checkout page URL will change from:
Before:
https://{store domain}/1234567890/checkouts/{checkoutToken}
└────┬────┘
storeId, removed in this updateAfter:
https://{store domain}/checkouts/{checkoutToken}Whether you or your service provider need to adapt depends on how your code uses these URLs, not which page it touches:
- Requires adaptation: Your code parses content from these page URLs, for example, determining page type, extracting storeId, or extracting checkoutToken. This type of code may retrieve incorrect values after the change.
- No action needed: You only receive the complete link provided by the platform and redirect directly, without parsing anything from the link. This scenario is not affected.
If your custom code, theme, apps, 301 redirects, or third-party integrations parse or depend on the old URL path, you'll need to adapt , see "4. Scenarios That Require Adaptation" for the full breakdown by category.
3. Full Path Comparison
The table below lists the before/after path format for each page. Every row is changing this time except the one marked "Not changing this time."
| Page | Before | After |
| Checkout page (including the checkout page itself) | |
|
| Checkout page (Thank you page) | |
|
| Order status page | |
|
| Processing page | |
|
| Stock problem page | |
|
| Rate-limit page | |
|
| Error page (checkout) | |
|
| Error page (order) | |
|
| Subscription rebind page | |
Does not include storeID, not changing |
How to Get storeId When You Need It:
- Store custom code: Read it from the global object injected by the platform, such as window.Shopline.storeId (see the "Official Guide").
- Open Platform apps: Get the storeId field from the app installation context or API response, see the "Open Platform Documentation"f or the relevant endpoints.
| Note: After this change, the storeId segment will be removed from the page URL. Do not parse storeId from the URL. |
4. Scenarios That Require Adaptation
First identify which category your code falls into — Open Platform app, or store custom code? Then check it against the corresponding table below.
4.1. Open Platform Apps
| Scenario | Affected? | How to Handle |
| Determine whether the current page is the checkout page / order status page from the page URL | Affected | Switch to a match compatible with both the old and new formats (see "4.4 Code Examples: Example 1") |
| Extract storeId from the page URL | Affected | Get it from the app context / API response instead, don't parse it from the URL (see "4.4 Code Examples: Example 2") |
| Extract checkoutToken / orderSeq from the page URL | Affected | Don't extract it from the URL. Get the identifier through the Open Platform API; see the Open Platform documentation. For scenarios not covered, submit an Open Platform ticket |
| Parse URL fields such as checkout_url returned by webhooks/APIs to extract values | Affected | This field is for redirection only , don't parse values from it. For fields like storeId or orderSeq, check the Open Platform documentation for the relevant endpoint; for scenarios not covered, submit a ticket |
| Manually construct checkout/order page links | Affected | Use the complete URL returned by the Open Platform API instead of constructing the path yourself (see "4.4 Code Examples: Example 3") |
| Simply receive the complete link from the platform and redirect / display it | Not affected | No action needed |
| Call the platform's OpenAPI endpoints (/api/...) | Not affected | API paths are outside the scope of this change |
4.2. Store Custom Code (Custom JS / HTML)
| Scenario | Affected? | How to Handle |
| Use location.pathname to determine page type and decide whether to run a script | Affected | See "4.4 Code Examples: Example 1" |
| Take a segment from location. pathname by index (e.g., treating split('/')[1] as storeId) | Affected | See "4.4 Code Examples: Example 2." This is the pattern most likely to be overlooked, after the change, the retrieved value becomes "checkouts" without throwing an error |
| Analytics/tracking scripts that group pages using path-based regex | Affected | See "4.4 Code Examples: Example 1"; also check the page grouping rules in your third-party analytics dashboard (e.g., GA) |
| Redirect logic or A/B split rules that depend on the path | Affected | See "4.4 Code Examples: Example 1" |
| Pure styling custom CSS | Generally not affected | If it uses URL-based conditional loading, handle it as above |
4.3. 301 Redirect Settings
Path: Admin Panel > Settings > Domains > 301 Redirects
| Scenario | Affected? | How to Handle |
| "Redirect from" contains /:storeId/checkouts | Affected | Add a matching rule for the new format (see "4.4 Code Examples: Example 4") |
| "Redirect to" contains /:storeId/checkouts | Affected | Add a matching rule for the new format (see "4.4 Code Examples: Example 4") |
4.4. Code Examples
Example 1: Determining Page Type
Incorrect:
// Breaks after the change: the regex hardcodes the leading numeric segment
if (/^\/\d+\/checkouts\//.test(location.pathname)) { /* ... */ }
if (location.pathname.split('/')[2] === 'checkouts') { /* ... */ }Recommended:
// Compatible with both old and new formats: only checks for the "checkouts" segment
// itself, regardless of what precedes it
const isCheckoutPage = /(^|\/)checkouts\/[^/]+/.test(location.pathname);
const isOrderPage = /(^|\/)orders\/[^/]+/.test(location.pathname);Example 2: Getting storeId
Incorrect:
// After the change, this retrieves "checkouts" — no error is thrown, but the value is wrong
const storeId = location.pathname.split('/')[1];Recommended:
// Get it from the context injected by the platform (the exact field depends on runtime)
const storeId = window.Shopline?.storeId;
// Open Platform apps: use the storeId field from the app installation context / API responseExample 3: Generating Links
Incorrect:
// Manually constructing the path (no form of manual construction works anymore)
const url = `https://${domain}/${storeId}/checkouts/${token}`;Recommended:
// Use the complete URL returned by the Open Platform API, and redirect directly
const url = response.checkoutUrl;The link returned by the platform always reflects the format currently valid for that store, you don't need to determine the cutover state yourself. If you need to generate a link for a scenario the current API doesn't cover, check the Open Platform documentation or submit an Open Platform ticket.
| Note: Don't parse identifiers like checkoutToken, orderSeq, or storeId from the URL. Use the endpoints provided by the Open Platform instead. |
Example 4: 301 Redirect Configuration
Original configuration:
// Original "Redirect from" or "Redirect to" configuration
/example storeId/checkoutsNew configuration to add:
// Add the corresponding configuration for the new format
/checkouts
5. Self-Check Checklist
Follow the three steps below to search your codebase and confirm each item. Self-check is only complete once every item has been confirmed.
Step 1: Search KeywordsStep 1: Search Keywords
checkouts orders thank_you stock_problems
processing overload checkoutToken orderSeq storeId
Step 2: Search Patterns (Regex)
\/\d+\/checkouts # Hardcoded numeric segment + checkouts
\/\d+\/orders # Hardcoded numeric segment + orders
:storeId\/checkouts # Route template syntax
\{storeId\}\/checkouts # Template string syntax
%s\/checkouts # Backend format-string syntax
pathname.*split # Taking a path segment by index
pathname.*match # Path regex matching
location\.pathname # Any use of pathname
Step 3: Confirm Each Item
- All page-type checks have been updated to support both the old and new formats
- storeId is no longer parsed from the URL path
- checkoutToken / orderSeq are no longer extracted from the URL path
- checkout_url fields are used only for redirection, no longer parsed for values
- Checkout/order page paths are no longer constructed manually — the complete URL from the Open Platform API is used instead
- Page grouping and conversion-goal path rules in third-party analytics dashboards (e.g., GA) have been updated
6. FAQ
Q1: Will old links stop working?
No. Links in the old format will continue to redirect automatically to the new URL and remain accessible long-term, you don't need to manually replace any links you've already sent, and no historical data migration is needed.
Q2: Will my customers notice this update?
No. Normal customer access, checkout, and page navigation are not affected, this update only changes the technical structure of the URL.
Q3: What happens if I don't complete adaptation before the deadline?
After September 19, 2026, the URL format will be fully switched to the new format, and SHOPLINE cannot revert it. If your custom code, apps, or third-party systems still depend on the old URL format to parse data, you may encounter data processing or functionality issues, and these often fail silently, without errors or a blank page. We recommend checking your integrations and completing adaptation as early as possible.
Q4: Will I encounter both formats at the same time during the rollout?
Yes. Stores switch over in batches, so different stores may be on different formats at different times. Build your adaptation to support both formats simultaneously, rather than treating it as an either/or check.
Q5: What if the link I get from an API doesn't match the store's current cutover state?
Just use it as-is. The link returned by the platform always points to the page currently valid for that store. Even if the format appears inconsistent with the cutover state, the platform handles the redirect automatically — you won't get a 404.
Q6: I need storeId, checkoutToken, or orderSeq, but I can't get them from the URL. What should I do?
Check the Open Platform documentation for the relevant endpoint. For scenarios not covered, submit an Open Platform ticket.
Q7: Will the OpenAPI endpoint paths change?
No. This update only changes buyer-facing page links; API paths are unaffected.
Q8: Will the checkoutUrl field in API responses change?
Yes. It will change from including storeId to no longer including it.
Q9: Will the subscription rebind page change?
No. That page's path never included storeId.
7. Need Assistance?
If you've confirmed you're affected but run into a scenario the current API doesn't cover during adaptation, or you still have questions about the decision criteria, submit an Open Platform ticket or contact your SHOPLINE account manager for help.