Correct payment_failed_url docs to reflect the deployed fallback behavior
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- openapi
- Domain
- api, documentation
Research direction
Start with the Campaign Cart API guide and campaigns/v1.yaml, checking the create-order example, payment-failure callout, decline-flow explanation, and generated reference. Confirm the event-source fallback semantics with the implementation owner, then reconcile the guide and schema while keeping payment_failed_url optional; done means all public descriptions match the verified fallback order.
Written by the indexing model from the issue text.
Description
The Campaign Cart API guide says an omitted payment_failed_url is accepted only when the request includes HTTP Referer, and otherwise order creation fails. That describes superseded behavior. Engineering confirmed deployment of additional fallbacks on 2026-06-25; a read-only check of the current implementation on 2026-09-21 confirms the fallback resolver remains present.
Affected public surfaces:
- Campaign Cart API guide: the create-order example comment, “Send a Payment Failure URL” callout, and decline-flow explanation.
- Campaigns OpenAPI specification:
CreateOrder.payment_failed_urlhas only a generic redirect description and does not explain fallback behavior.
Please reconcile the guide and schema with the current API behavior:
- Keep explicitly sending a suitable failure URL as the recommended integration practice.
- Remove the claim that omission of both the field and
Referernecessarily rejects the order. - Document the verified fallback order: explicit
payment_failed_url, thenReferer, then the campaign page URL header / available event-source fallback, then the origin ofsuccess_url. Confirm the precise event-source semantics with the implementation owner rather than describing it loosely as the shopper’s last page view. - Keep the field optional in the OpenAPI schema; do not add the obsolete conditional requirement or make it unconditionally required.
- Check the example, callouts, and generated reference agree.
This is a documentation correction request, not a request to change API behavior. Historical documentation work: #44. This issue intentionally contains no merchant records or internal implementation excerpts.
- Dominant language
- MDX
- Stars
- 2
- Forks
- 0
- Avg merge
- 6h 4m
- Merged PRs (30d)
- 13
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from NextCommerceCo/developer-docs
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
All issues in NextCommerceCo/developer-docs
Similar issues
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
AXERA-TECH/ax-llm#77 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
games-on-whales/wolf#509 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100