@agent-cards/sdk 0.23.21 → 0.23.22

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -2,6 +2,20 @@
2
2
 
3
3
  ## Unreleased
4
4
 
5
+ ## 0.23.22
6
+
7
+ - Keep a FastSpring checkout's session id out of your events and error messages. FastSpring's checkout, on every store's own host under `onfastspring.com`, sends the card to `/session/<id>/payment` (after `/popup-<name>` in a popup), and anyone who holds that session id can read the session's own page, its order and the token its requests carry. `redactUrl`, every event and every error message now show it as `{session}` on every FastSpring store host, as in `https://daisydisk.onfastspring.com/session/{session}/payment`. The SDK does not pause a FastSpring payment yet. No API or Vault release is needed.
8
+
9
+ - Recognize Toast's card request behind a dark launch. `syncRegistry()` now declares the `toast_pinned_key` capability (`SUPPORTED_CAPABILITIES`), and the API serves the recognizer only to an org Agentcard has enabled, so no other org's Toast checkout changes. For an enabled org, the frame's post to `https://payments.toasttab.com/v1/payment-methods` pauses when it is the guest card request under the key Agentcard pins; Apple Pay and Google Pay requests on the same URL continue untouched, and any other card request there fails with `request_without_card`. `authorize()` needs `amount` and `currency` above zero (`AmountRequiredError`), since Toast's request names no price. The cardholder's device seals the real card under Toast's key, and the SDK writes that sealed card over the agent's placeholder in `card.cardData` and changes no other byte before it continues the request; an approval whose served set is anything else fails as `PaymentOutcomeUnknownError` with reason `cse_substitutions_malformed`, and one read after its window as `cse_substitutions_expired`.
10
+
11
+ - Pay a Payrexx payment through the checkout relay, for a company Agentcard turns Payrexx on for (dark launch). A Payrexx merchant's page, `https://<merchant>.payrexx.com`, takes the card in Payrexx Pay's own card frame, which posts it to its own URL, `https://checkout.payrexx.com/?pspId=44&lang=<language>`. This build declares `payrexx_card_frame` on every sync, and the API serves the Payrexx entry only to a company Agentcard turned Payrexx on for, so every other company's Payrexx payments go through untouched, as for an unsupported processor. For an enabled company the SDK pauses only the frame's own one-time card request, and the API takes it only on a Payrexx page Agentcard reviewed, WWF Ost's (`wwfost.payrexx.com`) for now. It refuses any other page with `unsupported_checkout`, reason `payrexx_instance_unreviewed`, because a donation page may offer a monthly choice that it sends only in its own order request, which no card request shows, and the cardholder there would approve a one-time payment the page repeats. That request names the frame's total, but it only mints a token, and the merchant's page charges its own total later. So `authorize()` refuses one without `amount` above zero and `currency` (`AmountRequiredError`): send the total the page shows, and the API holds it to the frame's figure exactly. The cardholder's device sends the card through the checkout relay, and the frame gets Payrexx's answer: the token, or the start of 3-D Secure. When 3-D Secure starts, the frame posts the card again for the authentication and, after the bank's challenge, for the post-authentication. The approval's read then names until when it covers those two posts (`TokenReplay.followUpsUntil`), and while the Vault page stays open the cardholder's device sends each one with the real card, with no second prompt, and the frame gets Payrexx's answer. A challenge opens on the merchant's page in the agent's browser and needs a person at that browser. Any other post of the card to the frame fails in the browser, so Payrexx never receives the dummy card, and the checkout reads `unsupported` with reason `unsupported_payrexx_card_resend` and holds, keeping the approval's state. While a send is out, a new card request fails in the browser with a `blocked` event, `a follow-up send is in flight`, which an EBANX send also raises now. A send that fails holds the checkout, even one the frame sends while the card request's answer is still landing, so the SDK refuses the frame's next card request, an EBANX one too. A Payrexx payment also needs the matching API, Vault and checkout relay releases.
12
+
13
+ - Pay a Paygent checkout, for a company Agentcard turned Paygent on for (dark launch). The merchant's page hands its card fields to Paygent's own `PaygentToken.js`, which sends them to `https://token.paygent.co.jp/n/token/request` (`https://sandbox.paygent.co.jp/n/token/request` in test) and gives up 35 seconds later, too soon for an approval after the press that sends it. So the SDK sends the card only through `prepare({ psp: 'paygent', environment: 'production' })` (`'sandbox'` for Paygent's test host), before the press; without one, the SDK refuses the request before it asks the API, and sends nothing. The sync now also asks for `capabilities=paygent_token`. Once the cardholder approves, the press's request pauses, the cardholder's device sends the card to Paygent itself, and the page receives Paygent's single-use token and nothing else. One approval sends one card request: the SDK refuses a second press, and a request for a stored card's security code too. Paygent's request names no amount, so the cardholder approves the `amount` and `currency` you pass, and the API refuses a zero `amount` with `amount_required`, which `prepare()` names too. On Paygent's live host, Agentcard pays only a merchant it has reviewed, at its reviewed page, under its reviewed name, merchant id and token key, and in its currency (Tokyo Chinese School at `https://fundexapp.jp`, in yen, today). The API refuses any other with `unsupported_checkout`, or `unsupported_currency` for another currency, and `prepare()` fails with that code before anyone is asked. The API holds the reviewed merchants, so a merchant Agentcard reviews later needs no new SDK. The merchant's server runs 3-D Secure after the token, in your agent's browser. No live payment has gone through this route yet. A payment also needs the matching API and Vault releases.
14
+
15
+ - Pause Eximbay's payment window (where Korean merchants send a buyer who pays with a foreign card) for the cardholder's device. The sync now also asks for `capabilities=eximbay_hosted_payment_page`, and the API serves Eximbay's recognizer only for a company Agentcard turned Eximbay on for. The SDK pauses the merchant's signed entry form to `https://secureapi.eximbay.com/Gateway/BasicProcessor.krp` (or `secureapi.test.eximbay.com` for a test merchant), which carries no card, as a `hosted_form` authorization, and answers the paused navigation with the `submitted_on_device` page once the cardholder's device has paid it. The merchant's page posts that form in the page or into a window it opens. `attachToCdp` pauses the post in the page, and the post into a window the page opened once it has armed that window. Eximbay's popup integration opens the window and posts the entry into it at once, so that entry can leave before the window is armed, as the entry on windows the merchant's page opens says: the SDK then fails the window's next post, the step, and the checkout reads `unsupported`, with no card sent. `attachToPlaywright` pauses only the post in the page, because Playwright does not route a window the page opens, so attach to an Eximbay checkout with `attachToCdp`. Every other post a page the SDK watches makes to Eximbay, the step that opens its window, the window's amount query, its lookup of the card's first eight digits and its card post, carries the card your agent typed or follows it: the SDK fails each one and reads `unsupported` with reason `processor_card_page`. Matching API and Vault releases are required. Eximbay stays off for every company Agentcard has not turned it on for.
16
+
17
+ - Pause the card token request Clover's card form sends, for the cardholder's device. Clover's iframe, on a merchant's own page or in the Clover Payments plugin for WooCommerce, sends the card to `https://token.clover.com/v1/tokens` (`token-sandbox.dev.clover.com` in Clover's sandbox) with the number encrypted under Clover's key. The sync now also asks for `capabilities=clover_card_token`, and the API serves Clover's recognizer only for a company Agentcard turned Clover on for. The SDK pauses only the card frame's own request at that exact URL. The cardholder's device builds the request again with the real card and sends it to Clover itself, and the frame gets Clover's token. Clover's request names no price, so pass `amount` and `currency`, above zero: without them `authorize()` throws `AmountRequiredError` before anything is created. Matching API and Vault releases are required. Clover stays off for every company Agentcard has not turned it on for.
18
+
5
19
  ## 0.23.21
6
20
 
7
21
  - Pause ComGate's payment gateway, where most Czech and Slovak e-shops send the buyer, for the cardholder's device. The sync now also asks for `capabilities=comgate_hosted_payment_page`, and the API serves ComGate's recognizer only for a company Agentcard turned ComGate on for. The merchant's server creates the payment at ComGate and sends the buyer to `https://payN.comgate.cz/init?id=<transaction id>`. The SDK pauses that link, in the page, in a frame of it or in a window it opened, as a `hosted_form` authorization that carries the link alone, and answers the paused navigation with the `submitted_on_device` page once the cardholder's device has paid it. The link names no amount, so `authorize()` refuses one without `amount` and `currency`, above zero, with `AmountRequiredError`. Every request but a GET that your browser makes to ComGate's API (`payments.comgate.cz`, `payments-gcp.comgate.cz`) or its card frame hosts (`sec.comgate.cz`, `sec-gcp.comgate.cz`) carries the card your agent typed, part of it or its ciphertext, and the SDK fails each one and reads `unsupported` with reason `processor_card_page`. Your events and error messages name the link without its id. Matching API and Vault releases are required. ComGate stays off for every company Agentcard has not turned it on for.
package/PREFLIGHT.md CHANGED
@@ -211,8 +211,12 @@ HiPay (`hipay`) has no discovery rule in this table. HiPay's JavaScript SDK (`li
211
211
 
212
212
  Gravy Secure Fields (`gravy`) is identified from the loader its merchants load, `/secure-fields/latest/secure-fields.js` on `cdn.<merchant>.gr4vy.app` (or `cdn.sandbox.<merchant>.gr4vy.app`), but it is not in this table. It launches dark: the direct SDK pauses Gravy's card request, a `PUT` from Gravy's controller frame, only after `syncRegistry()` and only for an org Agentcard has enabled, so the bundled catalog leaves it out and a Gravy checkout stays `unknown`.
213
213
 
214
+ Toast (`toast`) has no discovery rule in this table while it launches dark: the direct SDK pauses Toast's card request only after `syncRegistry()` and only for an org Agentcard has enabled, so a Toast checkout stays `unknown` until a rule for Toast's payments frame ships with the release that serves it to every company.
215
+
214
216
  Paddle (`paddle_vgs`) has no discovery rule in this table. Paddle's checkout frame on `buy.paddle.com` names the tokenizer it sends the card through only after the buyer's first step, and Paddle can name another one for each checkout, so nothing on the page before that step says which one a checkout uses, and a Paddle checkout stays `unknown`. The direct SDK pauses the card request a VGS checkout sends to `vault.paddle.com/cards` only after `syncRegistry()`, only through a prepared checkout, and only for an org Agentcard has enabled. Read the Paddle row of the [README](./README.md) processor table for what the SDK covers.
215
217
 
218
+ Paygent (`paygent`) has no discovery rule in this table yet. Every Paygent card form loads Paygent's `PaygentToken.js`, so a rule would name every Paygent checkout while no Paygent payment has gone through, and a Paygent checkout stays `unknown`. The direct SDK pauses the token request to `token.paygent.co.jp/n/token/request` only after `syncRegistry()`, only through a prepared checkout, and only for an org Agentcard has enabled. Read the Paygent row of the [README](./README.md) processor table for what the SDK covers.
219
+
216
220
  The bundled direct SDK profile declares processor support for `one_time` purchases. The catalog carries each processor's request limitations and known exclusions. A detection rule does not cover every product or regional variant sold under the processor's name. For example, Moneris Hosted Tokenization and Moneris Checkout use different payment paths; the implemented adapter covers Hosted Tokenization.
217
221
 
218
222
  The catalog also carries reviewed hosted, regional, and versioned variants observed on live checkouts: Adyen secured fields on the regional live hosts and any release, the Square card element frame, dLocal Smart Fields releases, Mercado Pago secure fields and the guest Checkout Pro card form, and the Rapyd hosted checkout page. A variant the implemented adapter does not admit, such as the Tranzila terminal-root page, the Authorize.Net hosted payment form, or a Worldpay hosted payment page, identifies its processor and returns `unknown` with `processor_variant_unverified`. A new fingerprint never declares payment support by itself.
package/README.md CHANGED
@@ -281,6 +281,7 @@ Coverage is specific to the processor request format, merchant setup, browser tr
281
281
  | Pelecard (Iframe/Redirect 2.0) | dark: paused only for an org Agentcard enables for Pelecard, in test mode and live. One-time card payments on `gateway21` and `gateway20.pelecard.biz`; pass `amount`, `currency` and the page's total as `pageAmount`. A live checkout pays only with a card the cardholder stored. See [Pay a Pelecard checkout](#pay-a-pelecard-checkout) |
282
282
  | CreditGuard (Hyp PPS hosted payment page) | dark launch, prepared checkout only (see "Pay a CreditGuard checkout"): served to this build (`capabilities=creditguard_pps_process`) only for a company Agentcard enabled for it, and prepared or paid only for that company. The cardholder's device sends the card and the page reads CreditGuard's answer. 3-D Secure, OTP, installments, save-my-card and currency conversion are refused. No UAT or live capture yet |
283
283
  | Primer (Web SDK v2 hosted fields; Printful, GetYourGuide) | dark launch (mode `token`): only for an org Agentcard has enabled; see [Pay a Primer checkout](#pay-a-primer-checkout) |
284
+ | Toast (Toast's payments frame; Toast online ordering) | dark launch, mode `cse` under a pinned key: after `vault.syncRegistry()`, and only for an org Agentcard has enabled, the frame's post to `payments.toasttab.com/v1/payment-methods` pauses when it is the guest card request, always with the cardholder's approval, never autopilot. Pass `amount` and `currency`, above zero: the request names no price, so that is the total the cardholder approves. A card the page asks Toast to keep for later payments, or one sealed under another key, is refused. Apple Pay and Google Pay requests on the same URL continue untouched. No live payment has gone through this route yet |
284
285
  | Payrails web SDK (Blacklane, FlixBus) | dark launch (mode `device_encrypt`): only for an org Agentcard has enabled, and only the card form's single-use save and its single-use payment until card-on-file consent exists; see [Pay a Payrails checkout](#pay-a-payrails-checkout) |
285
286
  | Elavon Converge (Hosted Payment Page) | dark: paused only for an org Agentcard enables for Converge, always with the cardholder's approval, never autopilot. One credit card sale in US dollars per payment page on `api.convergepay.com` or `www.convergepay.com` (`api.demo.convergepay.com` in Converge's demo environment); no amount needed. See [Pay an Elavon Converge payment page](#pay-an-elavon-converge-payment-page) |
286
287
  | Moneris Hosted Tokenization (Moneris's card frame; Raisin donation pages) | dark launch: after `vault.syncRegistry()`, and only for an org Agentcard has enabled, the SDK pauses the frame's post to `/HPPtoken/request.php` on `www3.moneris.com` or `gateway.moneris.com` (`esqa.moneris.com` for a test row) when it carries the card number, expiry and CVD, always with the cardholder's approval. A live payment needs a merchant Agentcard reviewed: the profile id the frame names must be one pinned for the checkout page's origin (Jack.org's Raisin page today), or the create answers `unsupported_checkout`. A frame that leaves the expiry or CVD to the merchant's page, or a post to any other `request.php` URL, fails in the browser with a `blocked` event, `request_without_card`. The cardholder's device sends the card through the checkout relay, and the page gets Moneris's temporary token, which the merchant charges from its own server: pass `amount` and `currency`, the total the cardholder approves. Moneris Checkout (`/chkt/`, `/chktv2/`) is not supported |
@@ -291,6 +292,7 @@ Coverage is specific to the processor request format, merchant setup, browser tr
291
292
  | HiPay Enterprise (HiPay's hosted fields; France, Portugal, Italy, Spain) | dark launch: after `vault.syncRegistry()`, only for an org Agentcard has enabled, and only through `prepare({ psp: 'hipay', environment: 'production' })` (`'sandbox'` for HiPay's stage vault) at a merchant Agentcard reviewed, with `amount` and `currency` above zero. The hosted fields' post to `secure2-vault.hipay-tpp.com/rest/v2/token` pauses, the cardholder's device sends the card to HiPay directly, and the frame receives HiPay's token. The frame's number-only post and its `/update` fail in the browser (`hipay_number_only`, `hipay_update_refused`), and a request still unsent 12 seconds after the pause fails before the card leaves (`hipay_send_window_closed`). Agentcard has reviewed one merchant so far, HappyBulle: a live checkout prepares only at `https://www.happybulle.com`, with `merchant: 'HappyBulle'`; `prepare()` at any other page fails with `unsupported_checkout`, and so does the create for a card request under any public username but HappyBulle's own |
292
293
  | Amadeus Checkout (Air France, KLM) | dark: only for an org Agentcard enabled, and only through `prepare({ psp: 'amadeus_checkout', cardId })`. The Checkout Web SDK's card add pauses; every other action on its URL continues. Air France and KLM keep the expiry in their own form, so the agent types the stored card's real expiry there and the checkout pays only with that card. Every Data Collection Page store is refused as `amadeus_dcp_field_config_unreviewed`. No live purchase yet. See "Prepare an Amadeus Checkout card step" |
293
294
  | Paddle checkout (Paddle's card vault or TokenEx; any Paddle seller) | dark launch: after `vault.syncRegistry()`, and only for an org Agentcard has enabled. On a Paddle checkout whose card method names VGS, pay only through `prepare({ psp: 'paddle_vgs', environment: 'production' })` (`'sandbox'` for Paddle's sandbox) on an attachment whose `cardId` names the paying card; without one, `prepare()` fails with `card_required`. The frame's post to `vault.paddle.com/cards` pauses, the cardholder's device sends the card itself, and the frame receives the stored card's id; its second request after its 10-second timeout gets the same answer. Type `placeholderCard()`'s facts for that card into Paddle's form, and pass `amount` and `currency`, the total the cardholder approves. Only Visa, Mastercard and American Express cards are paid (`paddle_vgs_card_unsupported` otherwise), and a typed expiry or placeholder that is not the card's fails the create with `paddle_vgs_card_mismatch`. On the live vault, Agentcard pays a checkout at any Paddle seller's own https page; from any other page, such as `http://localhost:4000`, `prepare()` fails with `unsupported_checkout`. Paddle's vault keeps the card, so Paddle can charge it again without another approval, at a subscription's renewal for example. Paddle's `/pay` that follows names the approved card's first six and last four digits, expiry and brand: the SDK writes them over the ones Paddle's form read from the placeholder, and aborts a `/pay` that names another stored card or comes more than a minute later. On a Paddle checkout whose card method names TokenEx, call no `prepare()`: the SDK pauses Paddle's `/pay`, and once the cardholder approves it, writes the card the cardholder's device encrypted over the placeholder's. With a `paddle_vgs` preparation on the attachment, the SDK refuses that `/pay` with `checkout_changed`. A Paddle checkout that sends the card through Spreedly is not supported |
295
+ | Paygent (`PaygentToken.js`; Fundex donation forms) | dark launch: only for an org Agentcard enabled, after `vault.syncRegistry()`, and only through `prepare({ psp: 'paygent', environment: 'production' })` (`'sandbox'` for Paygent's test host) before the press that sends the card: the script gives up on its token request 35 seconds after sending it. The request to `token.paygent.co.jp/n/token/request` pauses, the cardholder's device sends the card itself, and the page receives Paygent's single-use token. One approval sends one card request, so the SDK refuses a second press, and a request for a stored card's security code too. Pass `amount` and `currency`, the total the cardholder approves. On the live host the API accepts only a reviewed merchant at its reviewed page, under its reviewed name, merchant id and token key, and in its currency (Tokyo Chinese School at `https://fundexapp.jp`, in yen), and refuses any other before anyone is asked. The merchant runs 3-D Secure after the token in the agent's browser. No live payment has gone through this route yet |
294
296
 
295
297
  The recognizer list, and the status of each reviewed Adyen merchant profile on
296
298
  your client, are fetched from the API at runtime (`agentcard.checkout.syncRegistry()`),
@@ -298,7 +300,7 @@ so new processors work without you shipping a release. `attachToCdp` derives the
298
300
  `Fetch.enable` url patterns from that same list rather than a constant, which is
299
301
  why the sync call belongs before the attach. `agentcard.checkout.cardUrlPatterns()` returns
300
302
  those patterns if you arm a CDP connection yourself. Call
301
- `GET /v2/checkout/recognizers?modes=token,cse,hosted_form,device_encrypt&capabilities=fiserv_card_capture,gmo_shared_pk,capture_context,juspay_txns.v1,datatrans_secure_fields_tokenize,authorize_net_dpm_form,pelecard_transaction,aci_split_card.v1,creditguard_pps_process,primer_payment_instruments,payrails_device_encrypt,converge_hpp_process,worldpay_eprotect_jsonp,wspay_confirm,shiji_sts_pinned_key,amadeus_checkout_actions.v1,worldline_mycheckout_form,verifone_card_capture,ekashu_hosted_payment_page,cybersource_sa_token_create,gravy_session_fields_put,moneris_hosted_tokenization,paddle_vgs_cards,paddle_tokenex_pay,redsys_hosted_payment_page,lyra_krypton_payment,payfast_card_pay,wix_payments_tokenize,paymongo_checkout_pay,pay_nl_card_token,hipay_vault_token,twoc2p_secure_pay,quickpay_hosted_payment_page,revolut_card_field,paypal_card_fields,gopay_card_form,comgate_hosted_payment_page,przelewy24_hosted_payment_page,makecommerce_card_frame,tokenex_iframe_tokenize,transbank_webpay_hosted_payment_page,sumup_checkout_process`
303
+ `GET /v2/checkout/recognizers?modes=token,cse,hosted_form,device_encrypt&capabilities=fiserv_card_capture,gmo_shared_pk,capture_context,juspay_txns.v1,datatrans_secure_fields_tokenize,authorize_net_dpm_form,pelecard_transaction,aci_split_card.v1,creditguard_pps_process,primer_payment_instruments,payrails_device_encrypt,converge_hpp_process,worldpay_eprotect_jsonp,wspay_confirm,shiji_sts_pinned_key,amadeus_checkout_actions.v1,worldline_mycheckout_form,verifone_card_capture,ekashu_hosted_payment_page,cybersource_sa_token_create,gravy_session_fields_put,moneris_hosted_tokenization,paddle_vgs_cards,paddle_tokenex_pay,redsys_hosted_payment_page,lyra_krypton_payment,payfast_card_pay,wix_payments_tokenize,paymongo_checkout_pay,pay_nl_card_token,hipay_vault_token,twoc2p_secure_pay,quickpay_hosted_payment_page,revolut_card_field,paypal_card_fields,gopay_card_form,comgate_hosted_payment_page,przelewy24_hosted_payment_page,makecommerce_card_frame,tokenex_iframe_tokenize,transbank_webpay_hosted_payment_page,sumup_checkout_process,clover_card_token,eximbay_hosted_payment_page`
302
304
  for the list this build syncs. The API serves Fiserv's card capture only to a
303
305
  build that lists `fiserv_card_capture`, and only for a company Agentcard turned
304
306
  Fiserv on for. An older SDK never pauses a Fiserv request it could not finish,
@@ -355,6 +357,14 @@ same way: this build pauses the merchant's signed entry form to
355
357
  `payment.quickpay.net` for the cardholder's device and fails every other post
356
358
  your browser makes to QuickPay, and the window's lookup of the typed card's
357
359
  first digits.
360
+ Eximbay's payment window (`eximbay_hosted_payment_page`) is served the same
361
+ way: this build pauses the merchant's signed entry form to
362
+ `secureapi.eximbay.com/Gateway/BasicProcessor.krp` for the cardholder's device
363
+ and fails every other post your browser makes to Eximbay. A merchant that opens
364
+ Eximbay's window in a new window gets the pause only under `attachToCdp`, and
365
+ only once the SDK has armed that window: an entry posted into a window the page
366
+ opens in the same moment can leave first, and the SDK then fails the window's
367
+ next post, so the checkout reads `unsupported` with no card sent.
358
368
  Revolut Business's card field (`revolut_card_field`) is served on the same
359
369
  terms: this build pauses the frame's card payment on `merchant.revolut.com`,
360
370
  the cardholder's device sends it to Revolut itself, and the frame gets
@@ -364,6 +374,16 @@ for now (dark launch), until a reviewed change binds GoPay's payee and amount
364
374
  to the approval: this build pauses the card frame's own post on
365
375
  `secure.gopay.com`, at a shop Agentcard reviewed, the cardholder's device sends
366
376
  it through the checkout relay, and the frame gets GoPay's answer.
377
+ Payrexx Pay's card frame (`payrexx_card_frame`) is served only to a build that
378
+ lists it, for a company Agentcard turned Payrexx on for: this build pauses the
379
+ frame's own one-time card request on `checkout.payrexx.com`, the cardholder's
380
+ device sends it through the checkout relay, and the frame gets Payrexx's
381
+ answer. The API takes it only on a Payrexx page Agentcard reviewed, WWF Ost's
382
+ for now, and refuses any other with `unsupported_checkout`
383
+ (`payrexx_instance_unreviewed`): a donation page may offer a monthly choice
384
+ that no card request shows. When that answer starts 3-D Secure, the device also sends the frame's
385
+ two 3-D Secure posts under the same approval, and every other post of the card
386
+ to the frame fails in your browser.
367
387
  ComGate's payment gateway (`comgate_hosted_payment_page`) is served only to a
368
388
  build that lists it, for a company Agentcard turned ComGate on for: this build
369
389
  pauses the gateway link the merchant sends the buyer to,
@@ -375,6 +395,12 @@ this build pauses the widget's card `PUT` to `api.sumup.com/v0.2/checkouts/<id>`
375
395
  the API takes it only for a reviewed SumUp merchant and at the `amount` the
376
396
  payment page shows, the cardholder's device sends it to SumUp, and the widget
377
397
  gets SumUp's answer.
398
+ Clover's card form (`clover_card_token`) is served on the same terms: this
399
+ build pauses the card token request Clover's card frame sends to
400
+ `token.clover.com/v1/tokens`, the cardholder's device builds it again with the
401
+ real card encrypted under Clover's key and sends it to Clover itself, and the
402
+ frame gets Clover's token. Clover's request names no price, so pass `amount`
403
+ and `currency`, above zero: that is the amount the cardholder approves.
378
404
  CyberSource Secure Acceptance's token
379
405
  create (`cybersource_sa_token_create`) is served on the same terms too; every
380
406
  other company keeps the stop every build applies to a card posted to Secure
@@ -12,6 +12,10 @@ declare var AMADEUS_CARD_URLS: Readonly<{
12
12
  dcp: readonly never[];
13
13
  }>;
14
14
  }>;
15
+ declare var AMADEUS_RELAY_HOSTS: Readonly<{
16
+ production: readonly string[];
17
+ sandbox: readonly string[];
18
+ }>;
15
19
  declare var AMADEUS_MERCHANT_EXPIRY_POLICIES: readonly string[];
16
20
  declare var AMADEUS_MERCHANT_EXPIRY_POLICY: string;
17
21
  declare var AMADEUS_REFUSAL_REASONS: readonly string[];
@@ -34,6 +38,7 @@ declare function injectAmadeusCard(body: any, card: any, options?: {}): {
34
38
  body: string;
35
39
  where: any[];
36
40
  };
41
+ declare function isAmadeusDeviceRequest(templateBody: any, deviceBody: any, environment: any): boolean;
37
42
  declare function amadeusResponseOutcome(status: any, body: any, { url, card }?: {}): {
38
43
  outcome: string;
39
44
  reason: string;
@@ -54,4 +59,4 @@ declare function sanitizeAmadeusResponse(body: any, url: any, card: any): string
54
59
  declare function amadeusFacts(body: any): {
55
60
  refusalCode: any;
56
61
  };
57
- export { AMADEUS_CARD_MOPID, AMADEUS_CARD_URLS, AMADEUS_CHECKOUT_CAPABILITY, AMADEUS_CHECKOUT_PSP, AMADEUS_DCP_REVIEWED_KEYS, AMADEUS_MERCHANT_EXPIRY_POLICIES, AMADEUS_MERCHANT_EXPIRY_POLICY, AMADEUS_REFUSAL_REASONS, amadeusBodyKind, amadeusCardUrl, amadeusEnvironment, amadeusFacts, amadeusPreparationUrls, amadeusRefusalMessage, amadeusRequestRefusal, amadeusResponseOutcome, amadeusSdkHostRefusal, amadeusVendorFor, injectAmadeusCard, isAmadeusCardUrl, isAmadeusDcpConfig, isPreparedAmadeusRequest, readAmadeusBody, sanitizeAmadeusResponse };
62
+ export { AMADEUS_CARD_MOPID, AMADEUS_CARD_URLS, AMADEUS_CHECKOUT_CAPABILITY, AMADEUS_CHECKOUT_PSP, AMADEUS_DCP_REVIEWED_KEYS, AMADEUS_MERCHANT_EXPIRY_POLICIES, AMADEUS_MERCHANT_EXPIRY_POLICY, AMADEUS_REFUSAL_REASONS, AMADEUS_RELAY_HOSTS, amadeusBodyKind, amadeusCardUrl, amadeusEnvironment, amadeusFacts, amadeusPreparationUrls, amadeusRefusalMessage, amadeusRequestRefusal, amadeusResponseOutcome, amadeusSdkHostRefusal, amadeusVendorFor, injectAmadeusCard, isAmadeusCardUrl, isAmadeusDcpConfig, isAmadeusDeviceRequest, isPreparedAmadeusRequest, readAmadeusBody, sanitizeAmadeusResponse };
@@ -1,6 +1,6 @@
1
1
  // @ts-nocheck
2
2
  // Generated from @agent-cards/payment-core. Do not edit.
3
- // artifact-sha256: d537d04a5cd64f34af196a0f6cec7a7f5319bb396d94824131857a04632aab0a
3
+ // artifact-sha256: 2f7fee05c7e7675b8929a13a4c2870f4d795c6d0b59cc616fb952c4a4d1cfe08
4
4
  // src/amadeus-body.js
5
5
  var AMADEUS_CARD_MOPID = /^creditcard[0-9]*$/;
6
6
  var record = (value) => value !== null && typeof value === "object" && !Array.isArray(value);
@@ -43,6 +43,10 @@ var AMADEUS_CARD_URLS = Object.freeze({
43
43
  dcp: Object.freeze([])
44
44
  })
45
45
  });
46
+ var AMADEUS_RELAY_HOSTS = /* @__PURE__ */ Object.freeze({
47
+ production: Object.freeze(["paypages.payment.amadeus.com"]),
48
+ sandbox: Object.freeze(["paypages.test.payment.amadeus.com"])
49
+ });
46
50
  var AMADEUS_MERCHANT_EXPIRY_POLICIES = Object.freeze(["refuse", "fill"]);
47
51
  var AMADEUS_MERCHANT_EXPIRY_POLICY = "fill";
48
52
  var AMADEUS_REFUSAL_REASONS = Object.freeze([
@@ -356,6 +360,26 @@ function injectAmadeusCard(body, card, options = {}) {
356
360
  write(holder, sound.name);
357
361
  return { body: JSON.stringify(value), where };
358
362
  }
363
+ function isAmadeusDeviceRequest(templateBody, deviceBody, environment) {
364
+ const page = readAmadeusBody(templateBody);
365
+ const device = readAmadeusBody(deviceBody);
366
+ if (!page || !device || !owns2(page, "PPID") || !owns2(device, "PPID") || sdkShapeRefusal(page) || sdkShapeRefusal(device))
367
+ return false;
368
+ const before = page.data.mopdata;
369
+ const after = device.data.mopdata;
370
+ const written = ["pan", "CVV", "expmonth", "expyear", ...owns2(before, "holdername") ? ["holdername"] : []];
371
+ if (!written.every((key) => owns2(after, key)))
372
+ return false;
373
+ const restored = readAmadeusBody(deviceBody);
374
+ for (const key of written)
375
+ restored.data.mopdata[key] = before[key];
376
+ if (JSON.stringify(restored) !== templateBody)
377
+ return false;
378
+ const cvcLength = after.vendor === "amex" ? 4 : 3;
379
+ if (amadeusVendorFor(after.pan) !== after.vendor || !digits(after.CVV, cvcLength, cvcLength) || !exact(MONTH, after.expmonth) || !exact(TWO_DIGITS, after.expyear) || owns2(after, "holdername") && after.holdername.trim() === "")
380
+ return false;
381
+ return environment === "sandbox" || after.pan !== before.pan;
382
+ }
359
383
  var RESPONSE_LIMIT = 32768;
360
384
  var DECLINE_LABELS = Object.freeze(["label_error_payment", "label_error_bin", "label_error_bin_vendor", "label_error_bin_type"]);
361
385
  var EXPIRED_LABELS = Object.freeze(["session_timeout", "ppid_expired"]);
@@ -546,4 +570,4 @@ function amadeusFacts(body) {
546
570
  const label = value ? sdkFailureLabel(value) : null;
547
571
  return { refusalCode: DECLINE_LABELS.includes(label) ? label : null };
548
572
  }
549
- export { AMADEUS_CARD_MOPID, AMADEUS_CARD_URLS, AMADEUS_CHECKOUT_CAPABILITY, AMADEUS_CHECKOUT_PSP, AMADEUS_DCP_REVIEWED_KEYS, AMADEUS_MERCHANT_EXPIRY_POLICIES, AMADEUS_MERCHANT_EXPIRY_POLICY, AMADEUS_REFUSAL_REASONS, amadeusBodyKind, amadeusCardUrl, amadeusEnvironment, amadeusFacts, amadeusPreparationUrls, amadeusRefusalMessage, amadeusRequestRefusal, amadeusResponseOutcome, amadeusSdkHostRefusal, amadeusVendorFor, injectAmadeusCard, isAmadeusCardUrl, isAmadeusDcpConfig, isPreparedAmadeusRequest, readAmadeusBody, sanitizeAmadeusResponse };
573
+ export { AMADEUS_CARD_MOPID, AMADEUS_CARD_URLS, AMADEUS_CHECKOUT_CAPABILITY, AMADEUS_CHECKOUT_PSP, AMADEUS_DCP_REVIEWED_KEYS, AMADEUS_MERCHANT_EXPIRY_POLICIES, AMADEUS_MERCHANT_EXPIRY_POLICY, AMADEUS_REFUSAL_REASONS, AMADEUS_RELAY_HOSTS, amadeusBodyKind, amadeusCardUrl, amadeusEnvironment, amadeusFacts, amadeusPreparationUrls, amadeusRefusalMessage, amadeusRequestRefusal, amadeusResponseOutcome, amadeusSdkHostRefusal, amadeusVendorFor, injectAmadeusCard, isAmadeusCardUrl, isAmadeusDcpConfig, isAmadeusDeviceRequest, isPreparedAmadeusRequest, readAmadeusBody, sanitizeAmadeusResponse };