Beyond the standard sale, the Payment operation supports value-added features. Most are conditional: they require merchant or terminal configuration, and some require minimum software versions. Confirm with Market Pay which apply to your contract before building against them — certification only covers features that are active.
Donation (Microdon)
A charity donation is added through the Market Pay extension block:
"MarketpayPaymentExtensions": {"AdditionalAmount": [{"Amount": 2, "Type": "Donation"}]}Supported since Master 1.3.5 / PayOnSite 4.5.0. Whether the terminal prompts the cardholder for a donation is terminal-side configuration (amount window rules configured per merchant) — the POS extension above is for POS-initiated donation amounts. The donation appears on the receipt; verify your receipt handling shows it.
Surcharge
Surcharge is applied by the terminal per merchant configuration and is reported in the response, not requested by the POS:
"MarketpayPaymentExtensions": {"Taxes": [{"TaxType": "Surcharge", "TaxPercentage": 10.0, "TaxAmount": 12.0}]}Your POS must read the surcharge from the response and reconcile the authorised total accordingly, and the receipt must show it. Conditional on surcharge merchant configuration.
Cashback
Cashback availability depends on merchant and acquirer configuration. In the two-step flow, CardAcquisitionTransaction carries a CashBackFlag. If cashback is in your scope, request the field-level contract for your configuration from Market Pay and validate against the API specification on api-hub — do not infer it from another merchant's integration.
Tip / gratuity
Tip support requires terminal configuration and PayOnSite 4.5.0 or later. Depending on configuration, the tip is captured on the terminal (cardholder prompt) or supplied by the POS. As with cashback, confirm the exact contract for your configuration against the api-hub specification before building.
Dynamic Currency Conversion (DCC)
DCC requires a configured DCC provider and additional setup. When active, the cardholder chooses the currency on the terminal and the response and receipts carry both amounts. DCC is entirely conditional — without provider configuration the flows never trigger, and certification includes DCC only when it is in scope.
Multi-store / multi-merchant
A single terminal can process transactions for different merchants. Send a standard payment request with the merchant identified in SaleData.SponsoredMerchant:
"SaleData": {"...": "...", "SponsoredMerchant": {"CommonName": "MARKET PAY", "Address": "120 RUE REAUMUR\n75002 PARIS", "CountryCode": "FR", "MerchantCategoryCode": "5411", "RegisteredIdentifier": "198703093982001"}}The response echoes the sponsored merchant, and receipts carry the correct merchant identity. If your estate is one-POS-many-terminals rather than one-terminal-many-merchants, that is a session topology question instead — see How the message model works, Rule 2.
Gift cards and loyalty
Gift cards are processed as a standard payment with a MarketpayPaymentExtensions product block (CardId2, ProductType); loyalty identification travels in LoyaltyData. Balances are read with Balance inquiry.
Note
Every feature on this page maps to a CONDITIONAL test in the certification suite — it is tested only if configured. Declare your active features when planning your test campaign so the right conditional tests are switched on.
Related
- Taking a payment — the base operation these features extend.
- Card acquisition and two-step payments — where cashback and donation appear in the two-step flow.