docs(connectors): BarclayCard SmartPay Fuse capability block from feature matrix - #283
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Address the three documented metadata and wallet setup guidance findings.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
Adds canonical BarclayCard SmartPay Fuse connector documentation and its navigation entry.
Changes:
- Adds capability and authentication documentation.
- Documents webhook behavior.
- Adds the connector to the alphabetical integration navigation.
File summaries
| File | Summary | Findings |
|---|---|---|
integration-space/SUMMARY.md |
Adds the BarclayCard navigation link. | None. |
integration-space/connectors-integrations/available-connectors/barclaycard.md |
Adds connector capabilities and setup guidance. | Three nit findings: document wallet prerequisites (line 39, 2 votes); use linked or labeled currency counts for 22 and 23 (line 29, 2 votes); add metaLinks.alternates (line 1, 2 votes). |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 3
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
nfarah86
marked this pull request as ready for review
September 18, 2026 17:26
Contributor
There was a problem hiding this comment.
🔵 Needs a closer look
Three moderate findings and three nits remain on the BarclayCard documentation page.
Review details
Suppressed comments (6)
integration-space/connectors-integrations/available-connectors/barclaycard.md:3
- All existing connector pages in this directory include
metaLinks.alternates(for example,boa.md:4-6). Omitting it here means this new route does not receive the repository's canonical/alternate metadata setup; add the page'sbarclaycard.mdalternate to the front matter.
---
description: Accept card and wallet payments through BarclayCard SmartPay Fuse.
---
integration-space/connectors-integrations/available-connectors/barclaycard.md:40
- The connector configuration marks wallet-specific fields as required (Apple Pay certificate/private key and merchant details, plus Google Pay merchant name/ID/key/auth methods), but this setup section only asks readers to enable the wallets. A merchant following these steps cannot complete wallet activation from the page and may hit connector-configuration failures; document these required fields or link to their setup instructions.
3. Enable only the card and wallet methods available on your connector account.
integration-space/connectors-integrations/available-connectors/barclaycard.md:7
- The connector code explicitly sets
mandatestoNotSupportedfor both card and wallet rows, and the table already saysnot supported; saying mandate reuse is only “not declared” makes an unavailable capability sound unknown. Please align this introductory sentence with the generated matrix.
BarclayCard SmartPay Fuse combines card acceptance with Apple Pay and Google Pay. Card routes support optional 3DS, refunds, and multiple capture choices. Mandate reuse is not declared for these payment routes.
integration-space/connectors-integrations/available-connectors/barclaycard.md:30
- These wallet currency cells are bare
22and23, so they render like ISO currency codes and do not tell readers that they are counts. The comparable generated rows incybersource/README.md:35-36include([full list](https://hyperswitch.io/pm-list)); please make this generated output expose the same link (and update the generator if necessary).
| wallet | Apple Pay | not supported | supported | automatic, manual, sequential automatic | not applicable | - | - | 22 |
| wallet | Google Pay | not supported | supported | automatic, manual, sequential automatic | not applicable | - | - | 23 |
integration-space/connectors-integrations/available-connectors/barclaycard.md:34
- The source includes
digestin theSignatureheader and signing string only for POST, whilebuild_headersadds aDigestheader for both POST and PUT. This sentence makes PUT look as though the digest is signed too; distinguish the POST signed digest from the PUT header to avoid incorrect implementations.
Supply **Key**, **Merchant ID**, and **Shared Secret**, the labels shown in the Hyperswitch control center. Hyperswitch Base64-decodes the Shared Secret, signs the ordered `host`, `date`, request-target, optional digest, and Merchant ID lines with HMAC-SHA256, then Base64-encodes the result. It sends the Key as `keyid` inside the `Signature` header and the Merchant ID in `v-c-merchant-id`; POST and PUT requests also carry a SHA-256 `Digest` header. See [`BarclaycardAuthType::try_from()`](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/crates/hyperswitch_connectors/src/connectors/barclaycard/transformers.rs#L51-L75), [`generate_signature()`](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/crates/hyperswitch_connectors/src/connectors/barclaycard.rs#L92-L132), and [`build_headers()`](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/crates/hyperswitch_connectors/src/connectors/barclaycard.rs#L159-L215).
integration-space/connectors-integrations/available-connectors/barclaycard.md:40
- These steps tell a merchant to enter three provider credentials but never explain where to obtain them. The other connector setup pages include a provider registration/dashboard step (for example,
bambora.md:40-43); without a verified SmartPay Fuse source, users cannot complete activation from this page. Add a verified credential-acquisition step or link to the provider's onboarding instructions.
1. Sign in to the [Hyperswitch control center](https://app.hyperswitch.io/).
2. Enter **Key**, **Merchant ID**, and **Shared Secret** during connector activation.
3. Enable only the card and wallet methods available on your connector account.
- Files reviewed: 2/2 changed files
- Comments generated: 0 new
- Review effort level: Lite
Align the page with the conventions the other connector pages follow and fix two statements that did not match the connector source. - Intro said mandate reuse was "not declared" while the table said "not supported". The source sets mandates: NotSupported on all four rows, so say that plainly and explain what it means for a merchant. - Authentication described a PUT branch that never runs. The only get_http_method overrides are PSync and RSync, both GET; everything else defaults to POST, so the Method::Put arm in build_headers is unreachable. Describe POST and GET only, and lead with the fact that the caller does not build the signature. - Apple Pay and Google Pay each require connector metadata beyond the payment-method toggle. Link the wallet setup guides and name the required fields, following the pattern in archipel.md. - Currency counts render as bare numbers that read like ISO codes. Add the pm-list link the other generated tables use; cybersource carries the same 22 and 23 with the link. - Restore the "tied to Hyperswitch <sha>" source-reference phrasing used by the other pages, which pins the SHA in prose rather than only in the link targets. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Address missing canonical metadata and clarify capture and wallet setup requirements.
Get a fresh assessment by requesting another Copilot review.
Review details
Suppressed comments (3)
integration-space/connectors-integrations/available-connectors/barclaycard.md:3
- The connector pages in this directory consistently declare a
metaLinks.alternatesentry (for example,archipel.md:3-5andauthipay.md:3-5), but this new page omits it. Add the canonical alternate metadata so BarclayCard follows the same docs routing/SEO convention as the other connector pages.
---
description: Accept card and wallet payments through BarclayCard SmartPay Fuse.
---
integration-space/connectors-integrations/available-connectors/barclaycard.md:44
- The Google Pay instructions omit three required fields from the same production connector configuration: Google Pay Public Key, Google Pay Private Key, and Recipient Id under
barclaycard.connector_wallets_details.google_pay(production.toml:1414-1455). As written, a merchant can follow this page and still be unable to complete the wallet configuration; list these fields as well, or explicitly scope the steps to the metadata-only flow.
5. To accept Google Pay, work through [Google Pay setup](../../wallets/google-pay/README.md) first. Activation then asks for the Google Pay merchant name, merchant ID, merchant key, and allowed authentication methods (`PAN_ONLY`, `CRYPTOGRAM_3DS`). All of them are required.
integration-space/connectors-integrations/available-connectors/barclaycard.md:43
- The Apple Pay metadata defines both the merchant certificate and private key as Base64-encoded fields (
crates/connector_configs/toml/production.toml:1336-1347), but this setup step does not tell users to encode them. Entering the PEM/key values directly will not match the connector's expected form; call out the required encoding for both values.
4. To accept Apple Pay, work through [Apple Pay setup](../../wallets/apple-pay/README.md) first. Activation then asks for the merchant certificate, merchant private key, Apple merchant identifier, display name, domain (`web` or `ios`), domain name, merchant business country, and where payments are processed (`Connector` or `Hyperswitch`). All of them are required.
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Lite
Every other connector page opens "Before you start" with a provider registration step; this page began at the Hyperswitch control center, leaving no indication that a SmartPay Fuse account is needed first. The step names no URL. Every config file, production.toml included, points barclaycard at api.smartpayfuse-test.barclaycard, so the only domain the code confirms is a test host, and the credential portal path is unverified. bluesnap.md sets the precedent for a registration step without a link. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
barclaycard appears in ucs_only_connectors in every deployment config. Where the Unified Connector Service is configured, that routes all of its traffic through UCS with no direct integration behind it, and the kill switch never diverts a UCS-only connector, as the comment on is_ucs_only_connector() states. Placed after the generated table, following the pattern bitpay.md uses for its refund caveat. The other UCS-only connectors with live pages (absa_sanlam, datatrans, moneris, elavon, rapyd) are unchanged here and will be handled in a separate PR. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The capability table prints automatic, manual and sequential automatic for both card routes; the summary listed only the first two, which understated a supported capture mode. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Matches the entry added to blackhawknetwork.md in ef7cca2, so the two pages in this batch carry the same front matter as the rest of the directory. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🔵 Needs a closer look
The Google Pay setup checklist is incomplete, and additional documentation corrections remain unresolved.
Review details
Suppressed comments (5)
integration-space/connectors-integrations/available-connectors/barclaycard.md:35
- At this commit,
ucs_only_connectorsis on line 1064 ofconfig/deployments/production.toml, while this URL targets#L1076in the following merchant-advice section. The reference therefore does not land on the evidence it claims to cite; point the anchor at the UCS list instead.
BarclayCard SmartPay Fuse is a UCS-only connector. Where the Unified Connector Service is configured, Hyperswitch sends all BarclayCard traffic through it and has no direct integration to fall back on, so the UCS kill switch never diverts this connector to a direct path. See the `ucs_only_connectors` list in [`config/deployments/production.toml`](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/config/deployments/production.toml#L1076) and [`determine_connector_integration_type()`](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/crates/router/src/core/unified_connector_service.rs#L883-L913).
integration-space/connectors-integrations/available-connectors/barclaycard.md:35
- The wording says that configuring UCS sends all traffic through it, but the router first checks whether UCS is enabled and available and uses the Direct gateway when it is disabled or unavailable. Qualify this operational note so operators are not misled about the fallback path; the kill switch limitation applies only to an active UCS path.
BarclayCard SmartPay Fuse is a UCS-only connector. Where the Unified Connector Service is configured, Hyperswitch sends all BarclayCard traffic through it and has no direct integration to fall back on, so the UCS kill switch never diverts this connector to a direct path. See the `ucs_only_connectors` list in [`config/deployments/production.toml`](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/config/deployments/production.toml#L1076) and [`determine_connector_integration_type()`](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/crates/router/src/core/unified_connector_service.rs#L883-L913).
integration-space/connectors-integrations/available-connectors/barclaycard.md:49
- These Apple Pay credentials are required in Base64 form: the metadata labels and linked Apple Pay setup instructions specify Base64-encoded certificate and private-key contents. Omitting that format can lead merchants to paste PEM/KEY contents directly and fail activation; call it out for both fields.
5. To accept Apple Pay, work through [Apple Pay setup](../../wallets/apple-pay/README.md) first. Activation then asks for the merchant certificate, merchant private key, Apple merchant identifier, display name, domain (`web` or `ios`), domain name, merchant business country, and where payments are processed (`Connector` or `Hyperswitch`). All of them are required.
integration-space/connectors-integrations/available-connectors/barclaycard.md:52
- The Google Pay checklist is incomplete:
connector_wallets_details.google_payalso marks Google Pay Public Key, Google Pay Private Key, and Recipient Id as required (in addition to the fourmetadata.google_payfields). The current link stops at line 1411, so a merchant can still miss required wallet credentials and fail activation; include these fields and link the full wallet-details configuration.
6. To accept Google Pay, work through [Google Pay setup](../../wallets/google-pay/README.md) first. Activation then asks for the Google Pay merchant name, merchant ID, merchant key, and allowed authentication methods (`PAN_ONLY`, `CRYPTOGRAM_3DS`). All of them are required.
The exact wallet field labels come from the [connector metadata configuration](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/crates/connector_configs/toml/production.toml#L1336-L1411).
integration-space/connectors-integrations/available-connectors/barclaycard.md:50
- The BarclayCard transformer requires an email and a complete billing address (first/last name, line 1, city, state, postal code, and country) for every card and wallet authorize request, returning missing-required-field errors before sending the request when they are absent. Add this API prerequisite to the setup checklist so credentials and wallet metadata are not presented as sufficient; this is the same connector-specific requirement documented for similar pages such as
cybersource/README.md:49.
5. To accept Apple Pay, work through [Apple Pay setup](../../wallets/apple-pay/README.md) first. Activation then asks for the merchant certificate, merchant private key, Apple merchant identifier, display name, domain (`web` or `ios`), domain name, merchant business country, and where payments are processed (`Connector` or `Hyperswitch`). All of them are required.
6. To accept Google Pay, work through [Google Pay setup](../../wallets/google-pay/README.md) first. Activation then asks for the Google Pay merchant name, merchant ID, merchant key, and allowed authentication methods (`PAN_ONLY`, `CRYPTOGRAM_3DS`). All of them are required.
- Files reviewed: 2/2 changed files
- Comments generated: 0 new
- Review effort level: Lite
I added these in response to a review comment. They were wrong twice over. gen_block.py's fmt() deliberately omits the link on country and currency cells: pm-list is a payment-methods page, not a country or currency list, and the linked count misled on every row (review, 11 Sep). Card network cells keep the link via list_networks, where pm-list is the right target. The linked pages in the corpus predate the v27 removal. The block is also generated and carries a do-not-edit marker, so the cells should not have been hand-edited at all. Restores the generator's actual output. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ed SHA Every one of these was against prose I added in the previous round, and every one is confirmed against hyperswitch at 9e5dd70d, which is the SHA this page pins rather than the tip I had checked out. - The ucs_only_connectors anchor pointed at L1076. At 9e5dd70d the list is on L1064; 1076 is my local checkout's line number. - The UCS note said the connector has no direct integration to fall back on. It has one: when UCS is disabled or its client is unavailable the router uses the Direct gateway. What is true is narrower and more useful, so the note now says the kill switch never diverts a UCS-only connector, and that the direct path behind one has never carried production traffic. - The Apple Pay fields are labelled Base64 Encoded for the certificate and the private key. A merchant pasting raw PEM would fail activation. - Google Pay needs seven required fields, not four. Public key, private key and recipient ID live in connector_wallets_details.google_pay, and the old link stopped at L1411, before any of them. - Every card and wallet authorize needs an email and a full billing address. build_bill_to() takes first name, last name, line 1, city, state, zip and country, and fails before the request is sent. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Final review comments retain documentation corrections for wallet setup and POST signing details.
Get a fresh assessment by requesting another Copilot review.
Review details
Suppressed comments (1)
integration-space/connectors-integrations/available-connectors/barclaycard.md:41
- The POST signing description is incomplete:
generate_signatureincludes thedigestfield in both theheaderslist and the HMAC input for POSTs, not onlyhost,date, request-target, and merchant ID. As written, readers cannot tell that theDigestheader is part of the signature; distinguish the POST and GET signing inputs.
Behind the scenes, Hyperswitch Base64-decodes the Shared Secret and uses it as an HMAC-SHA256 key over the `host`, `date`, request-target, and Merchant ID lines. The result goes out Base64-encoded in a `Signature` header that carries your Key as `keyid`, and the Merchant ID travels separately in `v-c-merchant-id`. Payment requests are POSTs: they also sign a SHA-256 digest of the body and send it in a `Digest` header. The sync flows are GETs, which have no body, so they carry neither. See [`BarclaycardAuthType::try_from()`](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/crates/hyperswitch_connectors/src/connectors/barclaycard/transformers.rs#L51-L75), [`generate_signature()`](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/crates/hyperswitch_connectors/src/connectors/barclaycard.rs#L92-L132), and [`build_headers()`](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/crates/hyperswitch_connectors/src/connectors/barclaycard.rs#L159-L215).
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Lite
The step listed all seven wallet fields as required. Google Pay has two configuration methods in the dashboard and the field set differs, so Payment Gateway merchants were being told to supply three fields they never see. GpayTokenParameters follows Google's spec: gateway and gateway_merchant_id are the PAYMENT_GATEWAY parameters, protocol_version and public_key the DIRECT ones. So Payment Gateway, where the connector decrypts, takes the four metadata.google_pay fields, and Direct, where Hyperswitch decrypts, adds the public key, private key and recipient ID from connector_wallets_details.google_pay. The step now names the choice, links the matching setup guide for each, and lists the fields per path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ector-page-20260915
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The only remaining feedback is a minor, non-blocking link correction.
Review details
Suppressed comments (1)
integration-space/connectors-integrations/available-connectors/barclaycard.md:35
- The production deployment file's
ucs_only_connectorsentry is at line 1075 in the pinned commit; line 1064 is the corresponding line insandbox.toml. This fragment therefore opens unrelated production configuration instead of the list it labels, so update the link to#L1075.
BarclayCard SmartPay Fuse is a UCS-only connector. While the Unified Connector Service is enabled, Hyperswitch routes every BarclayCard payment through it, and the UCS kill switch never diverts this connector to a direct path the way it can for others. If UCS is switched off or its client is unavailable, the router falls back to the direct implementation instead. Treat that fallback with care: the direct path behind a UCS-only connector has never carried production traffic. See the `ucs_only_connectors` list in [`config/deployments/production.toml`](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/config/deployments/production.toml#L1064), [`determine_connector_integration_type()`](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/crates/router/src/core/unified_connector_service.rs#L883-L913), the disabled-UCS arm in [`should_call_unified_connector_service()`](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/crates/router/src/core/unified_connector_service.rs#L971-L987), and [`is_kill_switch_applicable()`](https://github.com/juspay/hyperswitch/blob/9e5dd70d1cb4011bbcca3114862406008a0b61f8/crates/router/src/core/unified_connector_service.rs#L1130-L1152).
- Files reviewed: 2/2 changed files
- Comments generated: 0 new
- Review effort level: Lite
Clarified the message regarding webhook support and updated the phrasing for consistency.
The four GitBook status checks on 0ffb3e1 sat pending for five minutes with no update. The same checks pass on #278, #284 and #287, so this is not an outage. They are commit statuses from the GitBook app rather than Actions runs, so there is no run to re-run; a fresh push is what makes the app sync again. Empty commit, no content change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
Verdict: new-page-needed
PRs this responds to: none. This is connector backfill batch 3.
Placement
Evidence
BARCLAYCARD; display name: BarclayCard SmartPay Fuse; status: sandbox; category: bank_acquirer; no webhook flows; four rowscrates/connector_configs/toml/production.tomllines 1286-1334config/deployments/production.tomlline 50 andconfig/deployments/sandbox.tomlline 50crates/hyperswitch_connectors/src/connectors/barclaycard.rslines 1540-1712What I could not check
I could not check this from the sandbox: provider-side credential portal paths and decommission notices. I tried the provider sites, but those domains are not on the sandbox allowlist.
Decision requested
Approval of canonical placement, generated block, code-backed auth/webhook notes, and visible nav entry.
Review round 2 (nadine)
Copilot raised six findings. Five were valid and are fixed in 39a2c64 and 8219edc; one is declined. Two further defects and one correction to this description came out of reviewing against the other connector pages.
Fixed
not supported. The source setsmandates: FeatureStatus::NotSupportedon all four rows. Now stated plainly, with what it costs a merchant.Digestheader. Barclaycard never issues a PUT: the onlyget_http_methodoverrides arePSync(L901) andRSync(L1314), bothMethod::Get, and everything else defaults to POST, so theMethod::Putarm inbuild_headersis dead. Rewritten to POST and GET only. This goes further than the review comment, which asked only to distinguish the two.required=truemetadata fields and Google Pay 4. The page only said "enable the wallets". Now links the Apple Pay and Google Pay setup guides and names the fields, following the pattern inarchipel.md:50.Corrected after review
metaLinks.alternates. Added in 6a77b0e. I declined this at first, arguing the entries are written by GitBook on page moves rather than authored by hand, so a new route would have no prior path to alternate from. That was wrong. All 40 entries in the directory are self-referential and none points at a different prior path, which is not how a move-redirect record would look, andamazonpay.mdwas created carrying one in docs(connectors): Amazon Pay capability block from feature matrix #282, the preceding PR in this batch. The field is authored at page creation.bitpay.mdhas the same gap and is fixed in docs(connectors): Bitpay capability block from feature matrix #284;nmi.mdandrazorpay.mdpredate this batch.Found in review, not raised by Copilot
<sha>. See …"; this page said "follows …" and dropped the SHA, which is otherwise only visible by hovering a link. Restored.amazonpay.mddrifted the same way. This section is not emitted bygen_block.py, so it is prose convention rather than generator output.barclaycardis inucs_only_connectorsin every deployment config. Where UCS is configured it takes all of this connector's traffic with no direct integration behind it, and the kill switch never diverts a UCS-only connector. Now noted after the table.absa_sanlam,datatrans,moneris,elavonandrapydare in the same position with live pages and will be handled in a separate PR.Correction to this description
"Configured production and sandbox hostnames resolved" is misleading. Both resolve, but to the same host, and it is a test host: every config file,
config/deployments/production.tomlincluded, setsbarclaycard.base_url = "https://api.smartpayfuse-test.barclaycard/". Comparebankofamerica, which has distinctapi.andapitest.hosts. Harmless while the connector is sandbox-only, but it looks like an upstream bug and should have its own issue."The commit list may include main commits" no longer applies; the branch is merged with current main and the diff is the page plus the SUMMARY entry.
Still open
The provider portal path is still unverified, so the registration step names no URL. The only domain the code confirms is the test host above, and I would not manufacture a portal link from it.
bluesnap.mdsets the precedent for a registration step without one. If you have a SmartPay Fuse onboarding URL, that step should carry it.Correction: the currency-count change was wrong and is reverted
I initially added
([full list](https://hyperswitch.io/pm-list))to the two wallet currency cells, acting on a review comment. That was wrong on both counts and is reverted.gen_block.pycarries two cell formatters.list_networks()links to pm-list;fmt(), which renders Countries and Currencies, deliberately does not:The pages that do carry links predate the v27 pm-list removal, which the skill records as having split the corpus. The area is also explicitly frozen: "The mechanism for country and currency cells is an open decision, pm-list is the wrong target for them, and no further cell-format change ships until it is made."
The block is generated and marked do-not-edit, so those cells should not have been hand-edited regardless. The table now matches the generator's output.
The skill does say "a bare number with no path is a regression", so the reviewer's underlying observation stands. The replacement mechanism is the open decision above, not pm-list.