TWO-24814/TWO-24952: source payment terms + surcharge cap (+ default term) from the merchant API#236
Open
dgjlindsay wants to merge 1 commit into
Open
Conversation
…erchant API TWO-24814 / TWO-24952 / TWO-24859 The offerable payment terms, the buyer-surcharge cap and the merchant's default term are per-merchant commercial values — they vary between merchants of the same brand — so GET /v1/merchant is their authoritative source, not brand.xml. Mirrors the minimum-order-value pattern already in place. - Add Service/Merchant/RecordProvider: one verify_api_key -> GET /v1/merchant fetch, cached + memoised per API key. Single source of the merchant record for every consumer. - Add Service/Merchant/SettingsProvider: getAvailableTerms (available_terms), getSurchargeLimit (surcharge_limit), getDefaultTerm (due_in_days). - MinimumOrderProvider now consumes RecordProvider (parsing only); the fetch/cache protocol moved into the shared provider. - Admin payment-terms + surcharge-grid blocks and the AvailablePaymentTerms source model read the offerable terms and surcharge cap from the merchant API; the admin still narrows the buyer-facing term set. - getDefaultPaymentTerm prefers the merchant's due_in_days when it is an offered term, else the existing admin/lowest fallback. SettingsProvider is injected into ConfigRepository via a \Proxy to break the construction cycle. - Remove the now-unused getAvailablePaymentTerms / getSurchargeFixedMax from BrandRegistryInterface and its implementors, the Descriptor fields/getters, the Loader parse, and <available_payment_terms> from the vanilla brand.xml. brand.xsd keeps the elements optional for the transition. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
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
1 participant
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.
What
The offerable payment terms, the buyer-surcharge cap and the merchant's default term are per-merchant commercial values — they vary between merchants of the same brand — so
GET /v1/merchantis their authoritative source, notbrand.xml. This mirrors the minimum-order-value pattern already in the plugin.End state
Service/Merchant/RecordProvider— oneverify_api_key → GET /v1/merchantfetch, cached + memoised per API key. Single source of the merchant record for every consumer.Service/Merchant/SettingsProvider—getAvailableTerms(available_terms),getSurchargeLimit(surcharge_limit),getDefaultTerm(due_in_days).MinimumOrderProvidernow consumesRecordProvider(parsing only); its fetch/cache protocol moved into the shared provider — no behaviour change.AvailablePaymentTermssource model read the offerable terms and the surcharge cap from the merchant API. The admin still narrows the buyer-facing term set.getDefaultPaymentTermprefers the merchant'sdue_in_dayswhen it is an offered term, else the existing admin/lowest-available fallback (ABN-439 behaviour preserved).SettingsProvideris injected intoConfigRepositoryvia a\Proxyto break the construction cycle.getAvailablePaymentTerms/getSurchargeFixedMaxfromBrandRegistryInterfaceand its implementors, theDescriptorfields/getters, theLoaderparse, and<available_payment_terms>from the vanillabrand.xml.brand.xsdkeeps the elements optional for the transition.Scope / companion
Vanilla-engine half. A companion overlay PR removes the now-inert
<available_payment_terms>+<surcharge_fixed_max>from the ABNbrand.xml(they go dormant the moment this merges). Targetsstaging.Fresh-install note
When the API key is unset/invalid the offerable-terms set resolves empty (the admin can't offer terms until the key validates) — accepted, since a valid key always returns a non-empty set.
Tests
218 unit tests green (new
RecordProviderTest+SettingsProviderTest;MinimumOrderProviderTestslimmed to parsing;Repositorytests cover the API-preferred default term).phpstan+setup:di:compilerun in CI.PR description authored by Claude (Doug's session).