Merchant Management API — Update Merchant — Partners can now change a sub-merchant's details via PUT /v2/merchants/{id} instead of the dashboard. name and email are required on every call; type is fixed at creation and is ignored if sent, so a representation read from Show Merchant can be sent straight back. Two behaviours to be aware of before you integrate: a field you omit keeps its current value while a field you send empty is cleared, and changing email reassigns dashboard access — the new address is linked to the merchant (created and sent confirmation instructions if no account exists yet) and the previous address is unlinked from that merchant, though its account and any other merchants it belongs to are untouched. All merchant responses — list, show, create and update — now also return an updated_at timestamp. See Update Merchant.
Wero — Capture event on authorization — wero_capture_event is an optional parameter on Wero authorization requests (POST /rest/authorize). One of: SHIPPING, DELIVERY, AVAILABILITY, SERVICE_FULFILMENT, OTHER. When missing, falls back to OTHER. This information is displayed to the end user when making the payment. It is not accepted on payment or other requests. See Authorize API and Wero.
Jetztzahlen — Invoice activation — Invoices can be activated or deactivated via PUT/PATCH /rest/invoices/:invoice_number using the active flag. Deactivating an invoice stops its payment link and blocks further e-mails. amount and active can only be changed while the invoice is pending and has never had a payment plan attached. Creating or importing an invoice with an existing number in the same channel automatically deactivates the previous active invoice. Number-addressed endpoints always resolve to the active invoice (falling back to the most recently created). An invoice with an active payment plan cannot be deleted until the plan is cancelled. See Jetztzahlen, Update Invoice, and Delete Invoice.
Merchant Management API — Payment Methods — Partners can now discover and configure payment methods for their sub-merchants via the API. Browse the catalogue of available methods, processors and their field schema with GET /v2/payment-methods, then configure a method for a merchant or an individual shop (list, show, set and remove) via /v2/merchants/{merchant_id}/payment-methods and /v2/merchants/{merchant_id}/shops/{shop_id}/payment-methods. See Merchant Management API.
Wero — Checkout URL — wero_checkout_url is now required for Wero payments. It indicates where the user is coming from before making a Wero payment. See Payment API and Wero.
Wero — Payer location in postbacks — payer_location is now included in payment and refund postback data. This field is specific to Wero and only present when available. See Payment API and Refund API.
Card POS payment method — Accept card-present payments through physical POS terminals and SoftPOS devices. Supports payment, authorize + capture, full and partial refund, reverse, and unreferenced refund (payout). Single Tap online-PIN retries and switch_interface flows are surfaced via action_data.terminal_action in the synchronous response. Use payment_type: "cardpos" with the new pos_data request block. See Card POS.