Introduction

Generic flow

  1. e-shop server fetches configuration array of the shop (payment methods available). see shop configuration. (It makse sense to cache the conf locally and refresh it ca twice a day)
  2. when buyer reaches to checkout page - a selection of available payment methods is rendered based on the cached configuration
  3. user selects a payment method and proceeds to pay
  4. shop server now creates the transaction in MK API and recieves back an array of urls pointing to payment channels, specific to the transaction (see transaction)
  5. depending on method the user selected:
    • case banklink: user is redirected to the banklink url supplied by the ransaction creation response
    • case credit card: the MK Credit Card Dialog is launched by invoking checkout.js
  6. user completes the payment in the channel
  7. returning from:
    • bank link: user is redirected to return_url of the shop (specified in the shop config) with payment_return message
    • credit card dialog: user is redirected back with token_return message (POST to return_url.
  8. the shop will verify the message and state of transaction within and display successful payment confirmation page (or goes back to payment method selection step)
  9. MK servers will send additional async message about the transaction status change to the shop server notification_url (see notifications)

See also the Payment Gateway aka 'redirect method' that is even more simple way for integration.

There is also a small PHP SDK for API communication available in GitHub .