fix(homepage): route production onramp through vechain/onramp-proxy - #655
Merged
Conversation
#654 repointed deploy-cloudfront's NEXT_PUBLIC_TRANSAK_API_URL_PROD secret at vechain/onramp-proxy (GET contract) and fixed the next-template example's widgetUrlBuilder to match, but the actual production build (examples/homepage, deployed to vechainkit.vechain.org) was left on the old vechain-kit-infra POST/JSON contract — so the deployed widgetUrlBuilder now POSTs JSON to a GET-only endpoint and every production onramp call 405s. Ports the same production/staging branch already working in next-template.
|
Warning Review limit reached
Next review available in: 5 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (10)
📝 WalkthroughWalkthroughThe provider now uses a production onramp proxy for Transak widget URLs. It sends query parameters with GET, validates the response, and preserves the existing non-production POST flow. ChangesTransak widget URL flow
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
|
Size Change: +14.7 kB (+0.16%) Total Size: 9.03 MB
ℹ️ View Unchanged
|
Collaborator
Author
|
Verified locally against the real production endpoint before requesting review: → Opened the returned 🤖 Generated with Claude Code |
Reported: the "Add card details" step rendered clipped/overlapping the quote screen underneath it inside the embedded widget. Root cause (confirmed against @transak/ui-js-sdk@1.0.0's actual runtime): in containerId mode the SDK always renders the iframe at width:100%; height:100% of its container — widgetWidth/widgetHeight config options are silently ignored in that mode (they only apply to the SDK's own standalone overlay, used when no containerId is passed). So the container's own CSS is what bounds the widget, and both copies of it (TransakCheckoutModal, TransakOnrampContent) capped it at maxH="620px" — well under Transak's own documented single-embed sizing of `height: 80dvh` (docs.transak.com/integration/web/iframe), which is closer to what the deeper flow steps (KYC, add-card-details) actually need. Raises both containers to 80dvh (560-900px clamp) to match.
…frame
Reported on the preview deploy: opening the widget showed a blank white
container for a few seconds (the iframe loading Transak's remote app),
and the whole flow felt cramped -- the modal wasn't using the available
screen space.
- useTransakCheckout: track `widgetReady`, flipped by the SDK's
TRANSAK_WIDGET_INITIALISED event (previously unused). False from the
moment the widget opens until the iframe has actually rendered.
- TransakCheckoutModal / TransakOnrampContent: render a centered Spinner
as a sibling overlay while `!widgetReady` -- never as a child of the
SDK's own container div, since the SDK appends/removes the iframe via
direct DOM calls (containerId mode) that would fight React for that
node's children.
- TransakCheckoutModal: BaseModal size 'sm' -> 'lg' (Transak's own
single-embed sample uses a 500px-wide container; 'sm' was 384px).
- AccountModal: the 'transak-onramp' content type now gets its own
larger size/height ('lg', up to 90dvh) instead of the fixed 485px/'sm'
every other AccountModal screen uses -- that fixed cap was squeezing
an embedded external payment app (quote, KYC, add-card-details) into
a size tuned for simple menu/settings screens.
- New "Payments" page (mirrors the "Transactions" page's structure): PayWithTransakButton for the drop-in Buy VET button, plus a useTransakCheckout demo for a fully custom trigger. Added to the sidebar nav under Build, status NEW. - "Reading Data" page: new DemoSection for useTotalBalance -- one USD figure across liquid tokens + staking positions, the same total the AccountModal shows. - Wired transak config into the playground's VechainKitProviderWrapper (same dual-contract widgetUrlBuilder as the homepage example: prod -> vechain/onramp-proxy, staging -> vechain-kit-infra), gated on the new NEXT_PUBLIC_TRANSAK_* env vars (added to .env.example, all optional -- the Payments page degrades to the hook's built-in "not configured" error when unset, same as every other example integration here).
Collaborator
Author
|
Added to the playground (`examples/playground`):
🤖 Generated with Claude Code |
Vombato
approved these changes
Aug 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two fixes to the Transak onramp integration, bundled together per request.
1. Homepage widgetUrlBuilder didn't match the onramp-proxy contract
#654 repointed
deploy-cloudfront.yaml'sNEXT_PUBLIC_TRANSAK_API_URL(prod) atvechain/onramp-proxy— a GET-only endpoint (?provider=transak&address=..., response{url, partnerOrderId}) — and fixed theexamples/next-templateexample'swidgetUrlBuilderto match. It missedexamples/homepage, the app that actually builds and deploys tovechainkit.vechain.orgvia that same workflow, which was left POSTing the oldvechain-kit-infraJSON body to an endpoint that now only acceptsGET.Fix: ports the same production/staging branch already working in
next-template'swidgetUrlBuilderintoexamples/homepage's copy.Verified locally against the real production endpoint:
→
200 {"url": "https://global.transak.com?...", "partnerOrderId": "..."}— exact shape the fixedwidgetUrlBuildernow builds. Opened the returnedurl: the Transak widget renders cleanly (quote: $30 → ~5880 VET, Vechain Network, card payment available), no IP/ASN mismatch error (unlike the old vechain-kit-infra proxy).2. "Add card details" step rendered clipped/overlapping the quote screen
Reported via screenshot: inside the embedded widget, the card-details form overlapped the screen underneath it instead of replacing it cleanly.
Root cause (confirmed against
@transak/ui-js-sdk@1.0.0's actual runtime source): incontainerIdmode the SDK always renders its iframe atwidth:100%; height:100%of the container element —widgetWidth/widgetHeightconfig options are silently ignored in that mode (they only apply to the SDK's own standalone full-screen overlay, used when nocontainerIdis passed). So the container's own CSS is what actually bounds the widget, and both copies of it in this repo (TransakCheckoutModal,AccountModal/Contents/TransakOnramp/TransakOnrampContent) capped it atmaxH="620px"— well under Transak's own documented single-embed sizing ofheight: 80dvh(docs.transak.com/integration/web/iframe), which is what the deeper flow steps (KYC, add-card-details) actually need. The card-details screen didn't fit, so it rendered clipped and overlapping the quote screen behind it.Fix: raises both containers to
h="80dvh"(clamped560px–900px), matching Transak's own guidance.Verification: confirmed via the SDK's published source (
@transak/ui-js-sdk@1.0.0/lib/index.js) and Transak's iframe integration doc; not re-tested against the live "add card details" screen itself (would require a full wallet-connected session in the demo app taken deep into a real payment flow, which I avoided going further into than viewing).🤖 Generated with Claude Code