Update Payment metadata
Update (PATCH) an existing Payment’s metadata, identified by the payment’s payment_id.
Authorization: customer_token
Request parameters
Only the selected fields below can currently be updated. Any omitted fields will remain unchanged.
The following fields are non-editable. Attempting to edit these will return an API error:
amount, amount_total_with_surcharge, currency, created_at, fees, payment_details, payment_id, payment_method_id, recipient, recipient_account, sender, sender_account, , status, surcharge_amount, type, updated_at
Response fields
The response is the updated Payment object.
Refer to Payment object data model in GET /payments/{payment_id}.
Implementation guidance
Be careful when updating the value of a payment’s metadata, as this can impact downstream handling:
-
Some pre-built Finverse integrations (e.g. Rapidstor/Sitelink and Storeganise payments), rely on
payment.metadatato trigger downstream events, such as recording successful/failed payments in the integrated system. -
payment.metadatais included in payment webhooks sent by Finverse. If a webhook event is triggered after updatingpayment.metadata(e.g. due to apayment.statuschange), any listeners of the webhooks will automatically consume the metadata. Before updatingpayment.metadata, review how your webhook consumers handle changes to metadata.- Note: simply updating
payment.metadatawill not by itself trigger a webhook event.
- Note: simply updating
-
Consider how updated metadata can impact all possible downstream consumers of
payment.metadata, including:-
Pre-built Finverse integrations (which rely on metadata to record successful/failed payments)
-
Finverse payment statements (which display metadata)
-
ERP and accounting systems (for example, if they use metadata to allocate payments)
-
Analytics/business intelligence solutions, e.g. Power BI
-
Authorizations
The access token received from the authorization server in the OAuth 2.0 flow.
Path Parameters
payment id
Body
request body for updating payment
Customer-supplied attributes in key:value format. E.g. employer_name: Apple Inc. Any keys provided will be inserted as new keys into the existing metadata object, without removing any existing key:value pairs. If a key already exists in the metadata object, its value will be overwritten with the updated value provided.
Response
Successful
Amount of the payment (in minor currency unit)
100
Total amount of the payment including any transaction fee surcharge_amount paid by the sender (in minor currency unit). See surcharge_amount on transaction fee surcharges.
100
Transaction fee surcharge_amount paid by the sender, if any surcharge has been configured (in minor currency unit). Transaction fee surcharges are off by default, but can be set for specific payment methods, or for custom scenarios (e.g. based on transaction amount, payment flow, etc). Contact [email protected] to configure surcharges.
100
Timestamp when the payment was first created
Currency of the payment (e.g. HKD)
"HKD"
Details on why the payment failed (returned when status = FAILED). Note: this is used to detail any asynchronous e errors occuring after payment creation; any synchronous errors (e.g. API validation errors, real-time payment errors) will instead be returned directly during POST /payments.
Details on the fee(s) to be charged
Customer-supplied attributes in key:value format. E.g. employer_name: Apple Inc
Details on the payment
Finverse Payment ID for this payment. Always unique. Creating a payment with different idempotency keys will result in two payments with different IDs.
Details on the payment method
(TO BE DEPRECATED) Finverse unique ID for the payment method
Details on the recipient of the payment
Details on the recipient's account for the payment (i.e. the Customer App's settlement account at Finverse)
Details on the sender of the payment
(IN DEVELOPMENT) Details on the Sender's source institution and account, which is funding the payment
Current status of the payment. Possible values: CREATED, AUTHORIZATION_REQUIRED, PROCESSING, SUBMITTED, EXECUTED, CANCELLED, FAILED
AUTHORIZATION_REQUIRED, AUTHORIZING, PROCESSING, SUBMITTED, EXECUTED, FAILED, REVOKED, CANCELLED, CREATED Specified payment type. Possible values: - CARD: payment via card gateway (e.g. Stripe) - MANDATE: direct debit bank payment - MANUAL: manual bank transfer (e.g. FPS, PayNow) - SINGLE: not used (reserved for future use)
MANDATE, SINGLE, CARD, MANUAL, WALLET Timestamp of the last update to the payment's record