EAM Payload Data Content

If you wish to process account statements and use the content of EAM fields for this purpose, the table below uses the Original Account Statement format of the Raiffeisen Electra system. Request body

Field name	Content	Description	Rule
`paymentInfo`	EAM data
`transactionReference`	Transaction identifier	A point-to-point reference between the payment request sender and sub-aggregator used to identify the specific unique transaction. The mandate identifier can also appear in multiple messages related to the mandate.	Uniqueness must be ensured.
`transactionAmount`	Request amount	The requested amount in the currency specified by the payment request sender.
`transactionCurrency`	Currency	The currency code according to ISO 4217.	Only 'HUF' is allowed.
`expiryDateTimeOffset`	Validity period (in minutes)	The validity period of the data entry code is determined relative to creation time.	A maximum is defined per payment scenario.
`allowedModes`	Data entry mode	The data entry mode must be specified.
`qrAllowed`	QR data entry mode	The EAM can also be displayed in QR format.
`nfcAllowed`	NFC data entry mode	The EAM can also be read with an NFC device.
`deeplAllowed`	Deeplink data entry mode	The EAM can also be shared in deeplink format.
`remittanceInfo`	Unstructured payment reference	If the payment reference is marked as non-editable, the agreed information between the payer and beneficiary can be provided in this data field. Unstructured information enabling reconciliation of the incoming transfer with the item to be settled – e.g. a trade invoice on the buyer's current account.
`purposeCode`	Purpose code / Payment scenario identifier	End-to-end participants (initiating party, payer/(actual) debtor, and (actual) creditor) can communicate information about the nature of the transfer using the purpose code. Possible values: `IPEW`: Web purchase `IPPS`: In-store purchase
`deviceType`	Device type	The type of the sending device
`editableFields`	Editable fields
`isAmountEditable`	Amount editability	The EAM request sender can specify whether the amount is editable by the payer. If the amount is editable, it can be fulfilled at an amount different from the original – lower or higher – up to the instant transfer value limit.
`isRemittanceInformationEditable`	Payment reference editability	The EAM request sender can specify whether the payment reference is editable by the payer. If editable, the original payment reference can be overwritten.
`isCustomerIdEditable`	Customer identifier editability	The EAM request sender can specify whether the customer identifier is editable. If editable, the customer identifier can be modified by, for example, a Loyalty App in the payment chain.
`invoiceReference`	Invoice or receipt identifier	It may be necessary to specify an invoice or receipt identifier – e.g. in case of utility bill payments – the identifier of the invoice to be paid, as this helps with later traceability on both the payer's and beneficiary's side. Similarly, for retail transactions, it may be useful to provide the receipt identifier.
`customerReference`	Customer identifier	A customer identifier primarily appears in utility bill payments, where the service provider identifies its customers with a special identifier used only by that provider. In this case, it is necessary to include this in the transfer message, as it helps with unambiguous tracking of payments on both the payer's and beneficiary's side.
`payeeInfo`	Beneficiary
`accountNumber`	Beneficiary account in IBAN format	International bank account number of the beneficiary. In Hungary, it is a 28-character number string always starting with HU, and the last 24 characters match the account number. For a 2×8 character account number, the last eight digits of the IBAN are zeros.
`terminalReference`	Terminal identifier	Identifier of the beneficiary's device
`shopId`	Shop identifier	Serial number of the beneficiary's shop

Response body In case of successful API call (HTTP 200):

Field name	Note
`paymentReference`	Unique EAM identifier generated by the Aggregator
`creationDateTime`	Aggregator timestamp. Details of format handling are described in a separate section.
`expiryDateTimeOffset`	Value in minutes within the limit defined per payment scenario, determined by the Beneficiary within the value specified for the payment scenario.
`paymentUrl`	Unified data entry code

In case of error HTTP 400 – General (business validation) error; the calling party receives the error reasons in the response. Under the paymentReference field, the "errorCode" and "description" field pairs repeat. If there is a simple validation error, the errorDetails (field, invalidValue, errorDescription) fields appear only in that case. In all other cases, only errorId, errorCode and errorDescription.

Field name	Note
`errorId`	Value sent in the x-request-id field
`errorCode`	Unique error code identifier (see error code table for details)
`errorDescription`	Short explanation for technical errors and enum validation errors, associated with the specific error code.
`errorDetails`	In case of field validation errors, an array of error list.
`field`	Affected field.
`invalidValue`	Invalid value.
`errorDescription`	Short explanation associated with the error.

HTTP 403 – Forbidden The calling party does not have the right to initiate the given API call; this may occur if the x-api-key is incorrect.

HTTP 429 – Too Many Requests API Gateway rate limit exceeded. The system detected too many requests in a short period of time. Implement a retry strategy with exponential backoff. Error message: USAGE_PLAN_THROTTLING_LIMIT_EXCEEDED Detailed information and retry examples