Supported Payment Methods & Transaction Types

The PMG API supports the following payment methods:

Payment method name Payment method tag Sync/Async Supported shopper type Guarantee Funds final status delay
Alipay alipay Async E_COMMERCE YES  
Alipay In Store Shopper Device alipaycustomerqr Async CUSTOMER_PRESENT YES  
Alipay In Store QR code alipayqr Async CUSTOMER_PRESENT YES  
Bancontact bancontact Async E_COMMERCE YES  
EPS eps Async E COMMERCE    
giropay giropay Async E_COMMERCE YES  
iDEAL ideal Async E_COMMERCE YES  
Multibanco multibanco Async E_COMMERCE YES  
MyBank mybank Async E_COMMERCE NO 1 hour
Paysafecard paysafecard Async E_COMMERCE YES  
Przelewy24 (P24) p24 Async E_COMMERCE YES  
SafetyPay safetypay Async E_COMMERCE YES  
SEPA Direct Debit - Model A First sepamodelafirst Async E_COMMERCE YES  
SEPA Direct Debit - Model A Recurring sepamodelarecurring Sync E_COMMERCE YES  
Skrill skrill Async E_COMMERCE YES  
SOFORT Banking/SOFORT Uberweisung directpay Async E_COMMERCE NO 1 hour
Trustly trustly Async E_COMMERCE NO 7 days
Union Pay Unionpay Async E_COMMERCE    
Finnish Online Bank Transfer finishonlinbank Async E COMMERCE    
WeChat Pay wechatpay Async E_COMMERCE YES  
Wechat Pay in Store wechatqr Async CUSTOMER_PRESENT YES  
Wechat In Store Shopper Device wechatcustomerqr Async CUSTOMER_PRESENT YES  
Affin Bank (Malaysia) affinbank Async E_COMMERCE YES  
AmBank (Malaysia) ambank Async E_COMMERCE YES  
Boleto Bancario boleto Async E_COMMERCE YES  
Bradesco (Brazil) bradesco Async E_COMMERCE YES  
CIMB Clicks (Malaysia) cimbclicks Async E_COMMERCE YES  
Dragonpay (Philippines) dragonpay Async E_COMMERCE YES  
eNETS enets Async E_COMMERCE YES  
Maybank2U (Malaysia) maybanktwou Async E_COMMERCE YES  
Payu (Czeck and Polish Banklinks) payu Async E_COMMERCE YES  
POLi poli Async E_COMMERCE NO  
RHB Bank (Malaysia) rhbbank Async E_COMMERCE YES  


The supported transaction types are:

  • Transaction authorization – includes:
    • Processing with the payment provider of a transaction authorisation request
    • Notification of request status change and/or funds status change – initiated by PMG
  • Refund – includes:
    • Processing with the payment provider of a refund request
    • Notification of refund status change and/or funds status change – initiated by PMG
  • Check transaction/refund status – initiated by the API consumer – advisable to be triggered based on the status change notification
  • Cancellation (BLIK ONLY)
    • Correction when the service for the benefit of the user has been partly completed from the point of view of the merchant and as a result, there needs to be a correction to the transaction amount


There are some pre-requisites for successful processing of the requests described below in this document:

  • The merchant is successfully configured in PMG
  • The payment method being requested is supported by PMG
  • The payment method being requested is set to ACTIVE for the merchant

There could be also some pre-requisites or validations made by the payment provider or an external acquirer that processes the transaction on behalf of the payment method (e.g. min or max amount of the transaction, country/currencies supported, payment industries not allowed etc.) that are not implemented in PMG.