Payment API Reference #top

Version:

Payment API Reference

 Versions

Version Description
w3.1

API version w3.1 is used for card, terminal and e-payments. w3 is an older version (see the changelog for differences between the versions).

wm3.1
wp3.1

API version wm3.1 is a channel extension which adds two new fields to the product object that are only required for channel payments. wm3 is an older version (see the changelog for differences between the versions).

wp3.1 works similarly to wm3.1 with few differences:

  • A payment can't have products from multiple different merchants. Only one merchant is allowed.
  • This merchant is shown as the seller to the end customer during the payment process.


 Changelog

Date Changes
2024-01-24

Updated description of payment flow for inline frame card payments and the Customer object.

2024-01-11

Added phone field to the Customer object

2023-04-24

Fellow Lasku is now known as Alisa Lasku and Fellow Yrityslasku as Alisa Yrityslasku. No changes to API.

2023-04-13

Removed support for ISK currency.

2022-06-30

Added a new payment method: Nordea B2B. Payment method object selected value now supports a value nordeab2b and the group code banks includes Nordea B2B.

2022-06-15

Added a new payment method: OP Lasku. Payment method object selected value now supports a value oplasku and the group code creditinvoices includes OP Lasku.

2022-01-01

Version wp3.1 released. See versions for more information.

2021-08-17

Added a new payment method: Fellow Finance. Payment method object selected value now supports a value fellowfinance and the group code creditinvoices includes Fellow Finance.

2021-03-31

Updated token_valid_until parameter of the Payment method object to allow minimum value of 15 minutes from current timestamp.

2020-08-25

Added a new parameter override_auto_settlement to the Payment method object for overriding the auto settlement value in the merchant UI.

2019-10-09

Added support for Siirto service. Payment method object selected value now supports a value siirto and the group code wallets includes the Siirto service.

2019-09-04
2019-08-06

Added Initiator object and Verify object to Charge card token payments.

2019-06-25

New payment type embedded which replaces the old deprecated embedding method for card payments. See Inline frame card payments for more details.

2019-01-17

Marked Embedded Card Payment -flow as deprecated. Added ?minified GET-parameter for the payment page URL.

2018-09-25

Versions w3.1 and wm3.1 changes:

2018-04-16

Versions w3.1 and wm3.1 changes:

  • Support for terminal payments.
2018-01-10

Version w3.1 changes:

  • Support for multiple currencies. See currencies for more information.

Version wm3.1 released. This is a channel extension for w3.1.

2017-08-15

Added support for wallet services: MobilePay. Payment method object selected value now supports values wallets and mobilepay.

2016-09-01

Version w3.1 released. Main changes:

  • Validation error messages returned in the payment token and the charge card token requests.
  • Parametes card_verified, card_country, client_ip_country, error_code added to the source object.
  • The status of the payment can also be requested with an order number and new return code (reversed) for the payment status return.
2016-03-22

Version wm3 released.

2016-01-21

Added support for card token registration for e-payment-type payments.

2015-09-17

Version w3 released.

2015-06-02

Version wm1 released.

2015-05-18

Version w2.1 released.


 Payment flow

A payment token can be used only once and a new payment token is required for every order. For saving customer's credit card details see the description for a card token.

E-payments, hosted card payments and terminal payments

Inline frame card payments

This method may be used to implement banks, credit invoices and hosted card form payment methods.

Payment buttons can be embedded to your checkout page.

Steps:
  1. Request a payment token (type of e-payment or terminal)
    • (Optional) You may preselect a payment method (to skip the payment selection page)
  2. Redirect user to url generated from returned payment token
  3. Get return values from user return and / or from notify callback
Show sequence diagram

You have two options to implement embedded card payments to your checkout page.

The first way is to use our minified pay page inside an iframe.

The second option is to display our card form inside an iframe and then using postMessage method to pass a payment token to it.
The second option allows more flexible integration as it's possible to display the card form before a payment token has been created.

Compare the two options to find the best fit for your business.

Steps for the minified pay page:

  1. Request a payment token (type of e-payment)
  2. Open an inline frame with an url generated from returned payment token and use the ?minified GET parameter.
  3. Get return values from user return and / or from notify callback

Steps for the inline card form:

  1. Display our card form inside an iframe
  2. Request a payment token (type of embedded)
  3. Pass the token to the card form using postMessage method
  4. Get return values from user return and / or from notify callback

Note: Visa Secure Program has defined some cardholder related 3DS fields mandatory starting from August 12th 2024. When using the inline card form, make sure that the Payment token request includes a Customer object with at least the following fields related to the cardholder:

  • firstname
  • lastname
  • email

Charge card token

Customer's credit card details can be tokenized by requesting a card token in the payment token request.

A card token can be used multiple times and is suitable for example one click payment solutions or recurring payments.

There are two different ways a card token might be used.

In a Merchant initiated transaction (MIT) the payment is processed by the merchant on behalf of the cardholder and the cardholder is not present during the payment. This method should be used for recurring payments.

In a Customer initiated transaction (CIT) the card holder is present during the payment. In this case an additional card holder authentication might be required and this should be handled in your integration.

Steps to accuire a card token:

  1. To tokenize a card, set register_card_token to 1 in the payment token request
  2. Use the returned card token and set the initiator object according to use case (MIT or CIT) in the charge card token request. If the initiator is not set then the payment defaults to MIT
  3. In case of a CIT transaction, handle possible card holder authentication e.g. 3DS and redirect the customer using the returned verify object

See our general guidelines about how cards should be charged using a card token.


 Test credentials

The api can be tested with testing account (you may request one from here).

Available test cards and credentials can be found from the testing page.


 Currencies

The following currencies are supported by different payment methods. Currencies use ISO 4217 format.

Group code and payment method codes for the selected field are also displayed.

Payment method Group code Payment method codes Supported currencies
Card payments creditcards AED AFN ALL AMD ANG ARS AUD AWG AZN BAM BBD BDT BGN BMD BND BOB BRL BSD BWP BZD CAD CDF CHF CNY COP CRC CUP CVE CZK DKK DOP DZD EGP ERN ETB EUR FJD GBP GEL GHS GIP GMD GTQ GYD HKD HNL HRK HTG HUF IDR ILS INR IRR JMD KES KHR KZT LAK LBP LKR LRD MAD MDL MGA MKD MNT MOP MRO MUR MVR MWK MXN MYR MZN NAD NGN NIO NOK NPR NZD PAB PEN PGK PHP PKR PLN QAR RON RSD RUB SAR SBD SCR SEK SGD SLL SOS STD SVC SZL THB TOP TRY TTD TWD TZS UAH USD UYU UZS WST XCD YER ZAR ZMW
MobilePay wallets mobilepay DKK EUR NOK SEK
Pivo wallets pivo EUR
Siirto wallets siirto EUR
Banks banks nordea nordeab2b handelsbanken osuuspankki danskebank spankki saastopankki paikallisosuuspankki aktia alandsbanken omasaastopankki EUR
Invoices creditinvoices fellowfinance laskuyritykselle oplasku EUR


 Common objects

Common objects used with the API.

 Customer object

Note that Visa Secure Program has defined some cardholder related 3DS fields mandatory starting from August 12th 2024. We recommend that you send at least firstname, lastname and email.
Otherwise the customer will need to provide the missing information on our payment page.

Key Details
firstname
String
Customer's first name.
lastname
String
Customer's last name.
email
Email
Customer's email address.
address_street
String
Customer's street address.
address_city
String
Customer's city address.
address_zip
String
Customer's zip code.
phone
String
Customer's phone number. Should be provided in international format (e.g. +358400000000). If provided without country code (e.g. 0400000000), Finland (+358) is presumed.
address_country
String
Customer's country.
shipping_firstname
String
Customer's shipping address first name.
shipping_lastname
String
Customer's shipping address last name.
shipping_email
Email
Customer's shipping address email address.
shipping_address_street
String
Customer's shipping street address.
shipping_address_city
String
Customer's shipping city address.
shipping_address_zip
String
Customer's shipping address zip code.
shipping_address_country
String
Customer's shipping address country.
Example object
"customer": {  
  "firstname": "Test",
  "lastname": "Person",
  "email": "test.person@example.com",
  "address_street": "Testaddress 1",
  "address_city": "Testlandia",
  "address_zip": "123456"
}

 Product object

Products are always required for channel payments. For normal payments, products are not required but if one field is set then all fields are required.

Key Details
id
String required
Product's number / id. Shown in merchant UI. Might help connect products to actual products.
title
String required
Product's name. Shown in merchant UI.
count
Integer required
Amount of products.
tax
Integer required
Product's tax percent. Given as integer without %-sign e.g 24% = 24.
pretax_price
Integer required
Product's pretax price (price without tax). Must be in fractional monetary units e.g. 1€ = 100. Can also be negative if type is 4 (discount).
price
Integer required
Product's price (including tax). Must be in fractional monetary units e.g. 1€ = 100. Can also be negative if type is 4 (discount).
type
Integer required
Product's type. Used to identify different rows. Value 1 indicates normal product row. Value 2 indicates shipment costs. Value 3 indicates handling costs. Value 4 indicates discount.
merchant_id
Integer required for channel payments
ID of the merchant's sub merchant id that is attached to the channel. See settings page in the merchant portal for a list of all the sub merchants that have been attached to the channel merchant.
cp
String required for channel payments
Provision level ID for the product. See merchant portal for a list of all the provisions.
Example product array of objects
"products": [  
  {  
    "id": "as123",
    "title": "Product 1",
    "count": 2,
    "pretax_price": 100,
    "tax": 24,
    "price": 124,
    "type": 1
  },
  {  
    "id": "sku123",
    "title": "Product 2",
    "count": 1,
    "pretax_price": 100,
    "tax": 0,
    "price": 100,
    "type": 1
  },
  {  
    "id": "ab1",
    "title": "Shipping",
    "count": 1,
    "pretax_price": 199,
    "tax": 0,
    "price": 199,
    "type": 2
  }
]

 Source object

Key Details
object The type of the charge, card, terminal or e-payment.
brand The brand of the card used or if the object is e-payment or terminal, this is a payment facilitator's name.
Additional fields for terminal-object
customer_receipt Customer receipt text in base64 encoded string.
merchant_receipt Merchant receipt text in base64 encoded string.
signature_required Boolean integer defining if a signature should be requested from the customer.
id_check_required Boolean integer defining if the customer's id should be verified.
Additional fields for card-object
last4 The last four numbers of the card used.
exp_year The expiration year of the card.
exp_month The expiration month of the card.
card_token Card token. This field is only set if register_card_token was specified in the payment token request request.
Additional fields returned in the status check response for card-object.
card_verified

Tells information if the 3-D Secure was used. Determines how liability might be shifted from a merchant to a issuer in case of a chargeback due to fraud.

Value Explanation
Y 3-D Secure was used.
N 3-D Secure was not used.
A 3-D Secure was attempted but not supported by the card issuer or the card holder is not participating.
card_country The 2-letter ISO 3166-1 country code of the card.
client_ip_country The 2-letter ISO 3166-1 country code determined by the client IP address. If the country can not be specified, null is returned.
error_code

Detailed error code explaining why the payment might have failed. null is returned if there are no errors or no specific error can be determined.

See guidelines for handling these errors.

Value Explanation
04 The card is reported lost or stolen.
05 General decline. The card holder should contact the issuer to find out why the payment failed.
51 Insufficient funds. The card holder should verify that there is balance on the account and the online payments are actived.
54 Expired card.
61 Withdrawal amount limit exceeded.
62 Restricted card. The card holder should verify that the online payments are actived.
1000 Timeout communicating with the acquirer. The payment should be tried again later.
Example source object
"source": {
  "object": "card",
  "brand": "Visa",
  "last4": "4242",
  "exp_year": 2018,
  "exp_month": 5,
  "card_token": "sfasdfhmn39275y249035bhdfxslg",
  "card_verified": "Y",
  "card_country": "FI",
  "client_ip_country": "FI",
  "error_code": null
}

"source": {
  "object": "e-payment",
  "brand": "Nordea"
}

"source": {
  "object": "terminal",
  "brand": "Poplatek",
  "customer_receipt": "VmVsb2...",
  "merchant_receipt": "VmVsb2...",
  "signature_required": 0,
  "id_check_required": 0
}

 Payment token request

request url https://www.vismapay.com/pbwapi/auth_payment

request type HTTP JSON

Payment token request is done from backend to Visma Pay API.

 Payment token request fields

Key Details
version
String required
Version number. Should be w3.1 (or wm3.1 / wp3.1 for channel).
api_key
String required
The sub-merchant api key which is associated with the used private key. The sub-merchant api key is listed in the sub-merchants page in the merchant UI.
order_number
String required
The order number shall be unique for every payment and contain only numbers, letters (a-z), dashes and underscores.
amount
Integer required
Amount is in fractional monetary units e.g. 1€ = 100. Minimum value accepted is 1. If products are given amount must match with products' total prices.
currency
String required
See currencies for more information.
email
Email
Optionally provided customer's e-mail address for a payment receipt.
payment_method
Payment method object required
Payment method object.
authcode
String required

MAC code for the payment. It is calculated using HMAC-SHA256. HMAC implementations exist for most popular programming languages.

Sub-merchant private key is used as the secret key and the message is calculated from the values of the following fields:

  • api_key
  • order_number

Fields are joined with '|' character and they are appended in the specified order. The authcode must always be in UPPERCASE.

customer
Customer object
Customer object.
products
Array of product objects
Array of product objects.

 Payment method object

Key Details
type
String required

The type of the payment method. Possible values are e-payment, embedded and terminal.

Value Explanation
e-payment Used for banking payments and the card form in the pay page
embedded Used for the inline card form
terminal Used for terminal payments
register_card_token
Integer

Boolean integer defining if a card specific token should be registered. A card token is returned in the payment status check if a payment has been successful. 0 = do not register, 1 = register.

If e-payment-type is used, it might be good idea to limit visible payment methods to only credit cards using the selected-parameter.

Card token registration is not supported for terminal payments

return_url
Url required

A customer is redirected to this page after a payment. GET parameters can be added to the url as long as they do not confict with the ones that are returned.

notify_url
Url required

This URL is called after a payment has been marked to a final state (success or failed). The URL is called with the same GET parameters as return_url. The request is done by Visma Pay server so a customer browser session doesn't exist. The request is normally done after couple of minutes if a payment was processed properly but it can take up to 30 minutes if a payment status has to be checked from a payment processor's interface.

The interface is expecting a HTTP status code 200 if the query is caught. The notify request is retried up to 3 times. Only URLs with protocol default ports (https:443, http:80) are supported.

In some rare cases it's possible that the status of the transaction changes from failed to successful later. In such cases the notify request is done again.

lang
String
Language used in during the payment process, allowed values are fi (default), en, sv or ru
token_valid_until
Unix timestamp

Determines how long the payment link is active and can be reused to pay the order. Payment link deactivates after the payment changes to final state. Allowed values are 15 minutes from current timestamp to 7 days from current timestamp. Default value is 1 hour from current timestamp.

override_auto_settlement
Integer

Optional field for overriding the auto settlement value in the Merchant UI. If this parameter is not given or the value is 0 then the default option from the Merchant UI is used.

Value Explanation
0 The default value from the merchant portal is used.
1 Auto settlement is disabled and the payment is only authorized
2 Auto settlement is enabled and the payment is also captured

If auto-settlement is disabled, settlement can be done either manually from the Merchant UI or by using the settlement API call. Note that the settlement process is not used in bank payments (bank payments are always settled automatically).

The settlement process is supported by the following payment methods:

  • Cards
  • Mobilepay
  • Alisa Lasku
  • Alisa Yrityslasku
Additional fields for e-payment type
selected
Array

Optionally preselected payment methods which will be available for customer.

You can limit the set of available payment methods to allow usage of only defined banks, credit invoice systems or card payments.

If only one specific payment method is selected, the customer will be redirected automatically to the payment providers payment page. Exceptions to this are banks and creditinvoices, which are shorthands for displaying payment methods belonging to that category.

Make sure that all the selected payment methods support the currency you are using, otherwise the api will return a validation error.

See currencies for which currencies are supported by different payment methods.

Possible values
  • banks - enables all accessible bank payments
  • creditcards - enables all accessible card payments
  • creditinvoices - enables all accessible credit invoice payments
  • wallets - enables all accessible wallet payments
  • nordea, nordeab2b, handelsbanken, osuuspankki, danskebank, spankki, saastopankki, paikallisosuuspankki, aktia, alandsbanken,omasaastopankki
  • fellowfinance - Alisa Lasku allows payments between 20€ and 5000€
  • oplasku - OP Lasku allows payments up to 5000€
  • laskuyritykselle - Alisa Yrityslasku
  • mobilepay - MobilePay wallet service
  • pivo - Pivo wallet service
  • siirto - Siirto service
Additional fields for terminal type
selected_terminal
Array

Optionally preselected terminals which will be available for payment.

You can limit the set of available terminals to allow usage of only defined terminals.

If only one specific terminal is selected, there will be an automatic redirection to the Point-of-Sale page which connects to that terminal.

skip_receipt
Integer
Optional boolean integer defining if the receipt-page should be skipped after a succesful payment. 0 = do not skip (default), 1 = skip. If the receipt-page is skipped, the receipts need to be printed from the merchant's own system.
Example request body
{
  "version": "w3.1",
  "api_key": "15-ku74gbued",
  "order_number": "test-order-1415463675",
  "amount": 548,
  "currency": "EUR",
  "email": "test.person@example.com",
  "payment_method": {
    "type": "e-payment",
    "return_url": "https://test.shop.com/return",
    "notify_url": "https://test.shop.com/notify",
    "lang": "fi",
    "token_valid_until": "1442403776",
    "selected": [
      "nordea"
    ]
  },
  "authcode": "8DF90FF9582EC87C073ACEE5C6194E9E2280D6028D55...",
  "customer": {  
    "firstname": "Test",
    "lastname": "Person",
    "email": "test.person@example.com",
    "address_street": "Testaddress 1",
    "address_city": "Testlandia",
    "address_zip": "123456"
  },
  "products": [  
    {  
      "id": "as123",
      "title": "Product 1",
      "count": 2,
      "pretax_price": 100,
      "tax": 24,
      "price": 124,
      "type": 1
    },
    {  
      "id": "sku123",
      "title": "Product 2",
      "count": 1,
      "pretax_price": 100,
      "tax": 0,
      "price": 100,
      "type": 1
    },
    {  
      "id": "ab1",
      "title": "Shipping",
      "count": 1,
      "pretax_price": 200,
      "tax": 0,
      "price": 200,
      "type": 2
    }
  ]
}

 Payment token return

response type HTTP JSON

 Payment token return fields

Key Details
result

Result code.

Value Explanation
0Success
1Validation error
2Duplicate order_number
10Maintenance break
token

Payment identification token that will be used in charge request.

This value is only returned if result field was 0 (success).

type

The type of the token. Possible values are e-payment, embedded and terminal. See the charge redirection for e-payment and terminal types and displaying inline card form for the embedded type.

This value is only returned if result field was 0 (success).

errors

Array containing explanations of validation errors. Only returned if there have been specific validation errors.

Example response body
{
  "result": 0,
  "token": "kufoaskjhigrmkn45p2356n34",
  "type": "e-payment"
}

{
  "result": 1,
  "errors": [  
    "The amount must be an integer.",
    "The contact.email format is invalid.",
    "The product.price sum does not match with the total amount."
  ]
}

 Charge redirection

request url https://www.vismapay.com/pbwapi/token/{:token}

request type HTTP GET

Both e-payment and terminal payments use the same redirection url.

After the payment has been created and the type of the payment is e-payment or terminal, the user should be redirected to the url constructed from the returned token. This can be done with simple HTTP redirect to the request url.

If charge card token endpoint has returned verify object, the customer should be redirected to the given token URL for 3DS verification.

In terminal payments user will be redirected to terminal selection page unless there is only one terminal available for the merchant or defined in the selected_terminals field. In that case, user is redirected to the POS page.

You can also append the URL with ?minified GET parameter to get minified payment page. Minified payment page is stripped down to bare minimum and hence is easier to integrate as a part of your webshop. Minified payment page only shows a card form (no other payment methods). This payment page is optimized for iframe and mobile applications. If the default payment page is displayed in iframe, some bank- and ACS pages might not work correctly. The minified payment page forces the browser to make page redirects on window level instead of inside the iframe. This is done by setting target="_top" in the card form. If you use sandbox attribute in your iframe setup, make sure you have allow-top-navigation, allow-scripts, allow-same-origin and allow-forms parameters enabled.


 User & notify return

request type HTTP GET

After the payment has been done, the user is redirected to return_url specified in the original payment token request. Same parameters are also used in notify-request.

Key Details
RETURN_CODE Return value containing the numeric code for a payment result. 0 means successful, other values are error codes. See the table below.
ORDER_NUMBER Order number from the original payment request.
SETTLED

OPTIONAL: Only set when the transaction was successful (RETURN_CODE = 0). Defines whether the transaction was settled (e.g. billed from the credit card) or was the payment only authorized.

  • 0: Authorized
  • 1: Settled

User can choose whether the transaction should be settled during the payment by enabling auto-settlement option from Merchant UI. If auto-settlement is disabled, settlement can be done either manually from Merchant UI or by using the settlement API call. Note that the settlement process is not used in bank payments (bank payments are always settled automatically).

INCIDENT_ID OPTIONAL: Set only when an error has happened in processing a payment.
AUTHCODE MAC-code for the response. Calculated using HMAC-SHA256 and changing all letters to upper case and following form:
  • RETURN_CODE
  • ORDER_NUMBER
  • SETTLED if set
  • INCIDENT_ID if set

Fields are joined with '|' character if present.
if INCIDENT_ID or SETTLED is set, it is added to end.

Example 1:
Private key "xad3b23s2a0d0328b4ea08yd95", return code 0, order number 12345 and settled 1

The fields are joined with '|' characted and AUTHCODE is calculated from the following string:
0|12345|1

Result after HMAC-SHA256 and uppercasing:
CCE582990AFB0BFF29A928E8B47E88403505AAF083181E8A7F93B7A42C306E77

Example 2:
Private key "xad3b23s2a0d0328b4ea08yd95", return code 1, order number 12345

The fields are joined with '|' characted and AUTHCODE is calculated from the following string:
1|12345

Result after HMAC-SHA256 and uppercasing:
864F74A47EDEDE35FBD3676C4F41376157AD54D17164633E09A54C4BAD1E573F

 Return codes

In a notify request only return values 0 or 1 are used.

Return code Explanation
0 Payment completed successfully.
1 Payment failed. Customer did not successfully finish the payment.
4 Transaction status could not be updated after customer returned from the web page of a bank. Please use the merchant UI to resolve the payment status.
10 Maintenance break. The transaction is not created and the user has been notified and transferred back to the cancel address.
Example
GET https://test.shop.com/return/?RETURN_CODE=0&ORDER_NUMBER=12345&SETTLED=1&AUTHCODE=640B574C2A93E16D30644BEE28CD3F511672D5BB957B2C6CD95F9F2EEDAB398C HTTP/1.1

 Displaying inline card form

iframe url https://www.vismapay.com/e-payments/embedded_card_form?lang={fi,en,sv,ru}

The inline card form page forces the browser to make page redirects (e.g. 3DS redirects) on a window level instead of inside the iframe. This is done by setting target="_top" in the inline form. If you use sandbox attribute in your iframe setup, make sure you have allow-top-navigation, allow-scripts, allow-same-origin and allow-forms parameters enabled.

Key Details
lang The language of the inline card form. Possible values are fi, en, sv or ru.
<iframe id="iframe" height="220px" src="https://www.vismapay.com/e-payments/embedded_card_form?lang=en"></iframe>

 Charging inline card form

After you have requested a payment token you can charge the inline card form by sending the token using postMessage to the iframe.

The charge message is in JSON and the fields are described below.

If card details are inputted correctly to the form, a user is redirected on a window level and eventually to the return_url given in the payment token request. See the returned fields for parsing the user return.

 Charge message fields

Key Details
action Must be pay
token The payment token

 Validate message fields

To catch a response you should add an event listener to your page. The response tells if card details are inputted correctly to the inline card form.

Key Details
action Must be validate

 Validate response event

Key Details
valid Either true or false.
Example charge message
var chargeMessage = {
	action: "pay",
	token: "kufoaskjhigrmkn45p2356n34"
}

document.getElementById("iframe").contentWindow.postMessage(
	JSON.stringify(chargeMessage), 
	"https://www.vismapay.com/"
)
Example validate event
// add an event listener
window.addEventListener('message', function(event) {
	var data = JSON.parse(event.data);

	if(data.valid)
	{
		// the inline card form is validated successfully
	}
})

var validateMessage = {
	action: "validate"
}

document.getElementById("iframe").contentWindow.postMessage(
	JSON.stringify(validateMessage), 
	"https://www.vismapay.com/"
)

 Charge card token request

request url https://www.vismapay.com/pbwapi/charge_card_token

request type HTTP JSON

Charge a card with a card token. This call can be used for recurring and one click payments. For the first charge, and to acquire required card_token, generate payment token, charge customer and check the payment status (returns the card_token).

If the initiator object type is set to 2 (Customer Initiated Transaction), the issuer might require 3DS authentication. If 3DS is required the endpoint will return verify object with type 3ds. The customer should be redirected to the given token url for 3DS authentication like in the charge redirect.

 Charge card token request fields

Key Details
version
String required
Version number. Should be w3.1 (or wm3.1 / wp3.1 for channel).
api_key
String required
The sub-merchant api key which is associated with the used private key. The sub-merchant api key is listed in the sub-merchants page in the merchant UI.
order_number
String required
The order number shall be unique for every payment and contain only numbers, letters (a-z), dashes and underscores.
amount
Integer required
Amount is in fractional monetary units e.g. 1€ = 100. Minimum value accepted is 1. If products are given amount must match with products' total prices.
currency
String required
See currencies for more information.
email
Email
Optionally provided customer's e-mail address for a payment receipt.
card_token
String required
Card token.
authcode
String required

MAC code for the payment. It is calculated using HMAC-SHA256. HMAC implementations exist for most popular programming languages.

Sub-merchant private key is used as the secret key and the message is calculated from the values of the following fields:

  • api_key
  • order_number
  • card_token

Fields are joined with '|' character and they are appended in the specified order. The authcode must always be in UPPERCASE.

customer
Customer object
Customer object.
products
Array of product objects
Array of product objects.
initiator
Initiator object
Initiator object. If not set, defaults to MIT and in case of 3DS is required the transaction is automatically declined.

 Initiator object

Key Details
type
Integer

Payment initiator. In case of CIT, 3DS might be required.

Value Explanation
1 Merchant initiated transaction (MIT)
2 Customer initiated transaction (CIT)
return_url
Url

Return url is only requrired if the initiator type is CIT.

A customer is redirected to this page after a payment and 3DS has been completed. GET parameters can be added to the url as long as they do not confict with the ones that are returned.

notify_url
Url

Notify url is only requrired if the initiator type is CIT.

This URL is called after a payment has been marked to a final state (success or failed). The URL is called with the same GET parameters as return_url. The request is done by Visma Pay server so a customer browser session doesn't exist. The request is normally done after couple of minutes if a payment was processed properly but it can take up to 30 minutes if a payment status has to be checked from a payment processor's interface.

The interface is expecting a HTTP status code 200 if the query is caught. The notify request is retried up to 3 times. Only URLs with protocol default ports (https:443, http:80) are supported.

In some rare cases it's possible that the status of the transaction changes from failed to successful later. In such cases the notify request is done again.

lang
String
Language used in during the payment process, allowed values are fi (default), en, sv or ru. Only used if the initiator type is CIT.
browser_info
Browser info object

Browser info object. Information about the browser used by the customer. Necessary to support 3DSv2 which some issuers will be using. Only used if the initiator type is CIT.

 Browser info object

Key Details
accept_header
String
Content of the HTTP accept headers. For example: "text/html,application/xml;q=0.9,*/*;q=0.8"
java_enabled
Integer
Boolean integer indicating whether browser can execute Java or not. Should be either 0 or 1.
language
String
Language of the browser as defined IETF's BCP47. For example: "fi-FI".
color_depth
Integer
Bit depth of the color palette. For example: 24.
screen_height
Integer
Height of the user's screen, in pixels. For example: 1080.
screen_width
Integer
Width of the user's screen, in pixels. For example: 1920.
timezone_offset
Integer
Time difference between UTC time and the browser time in minutes. For example: 120.
user_agent
String
Content of the HTTP user-agent header. For example "Mozilla/5.0".
Example request body
{
  "version": "w3.1",
  "api_key": "15-ku74gbued",
  "order_number": "test-order-2415442341",
  "amount": 547,
  "currency": "EUR",
  "card_token": "sdlklky4456ggi84358",
  "authcode": "C71FA1F5C34C3558DC57E07034C7EF8DDAF7C5C0BB8A...",
  "customer": {  
    "firstname": "Test",
    "lastname": "Person",
    "email": "test.person@example.com",
    "address_street": "Testaddress 1",
    "address_city": "Testlandia",
    "address_zip": "123456"
  },
  "products": [  
    {  
      "id": "as123",
      "title": "Product 1",
      "count": 2,
      "pretax_price": 100,
      "tax": 24,
      "price": 124,
      "type": 1
    },
    {  
      "id": "sku123",
      "title": "Product 2",
      "count": 1,
      "pretax_price": 100,
      "tax": 0,
      "price": 100,
      "type": 1
    },
    {  
      "id": "ab1",
      "title": "Shipping",
      "count": 1,
      "pretax_price": 199,
      "tax": 0,
      "price": 199,
      "type": 2
    }
  }
  ],
  "initiator": {
    "type": 2,
    "return_url": "https://test.shop.com/return",
    "notify_url": "https://test.shop.com/notify",
    "lang": "fi",
    "browser_info": {
      "accept_header": "text/html,application/xml;q=0.9,*/*;q=0.8",
      "java_enabled": 1,
      "language": "fi-FI",
      "color_depth": 32,
      "screen_height": 1080,
      "screen_width": 1920,
      "timezone_offset": 120,
      "user_agent": "Mozilla/5.0"
    }
  }
}

 Charge card token return

response type HTTP JSON

 Charge card token return fields

Key Details
result Result code.
Value Explanation
0Success
303DS verification is required
1Validation error or invalid token
2Duplicate order_number
3card_token not found
10Maintenance break
settled Only set when the transaction was successful (result = 0). Defines whether the transaction was settled (e.g. billed from the credit card) or was the payment only authorized.
Value Explanation
0 authorized / not settled
1 settled
source
Source object

Source object.

errors

Array containing explanations of validation errors. Only returned if there have been specific validation errors.

verify
Verify object

Returned if result was 30. Customer should be redirected for 3DS authentication.

 Verify object

Key Details
token

Verification identification token that will be used for redirection like in charge redirect.

type

The type of the token. Always 3ds if this object is returned.

Example responses
{
  "result": 0,
  "settled": 1,
  "source": {
    "object": "card",
    "last4": "4242",
    "brand": "Visa",
    "exp_year": 2018,
    "exp_month": 5,
    "card_token": "sfasdfhmn39275y249035bhdfxslg",
    "error_code": null
  }
}

{
  "result": 30,
  "verify": {
    "token": "kufoaskjhigrmkn45p2356n34",
    "type": "3ds"
  }
}

 Payment status request

request url https://www.vismapay.com/pbwapi/check_payment_status

request type HTTP JSON

Payment status request is done from backend to Visma Pay API.

 Payment status request fields

Key Details
version
String required
Version number. Should be w3.1 (or wm3.1 / wp3.1 for channel).
api_key
String required
The sub-merchant api key which is associated with the used private key. The sub-merchant api key is listed in the sub-merchants page in the merchant UI.
token
String
Token returned for the payment request. Either token or order_number is required.
order_number
String
The order number of the payment. Either token or order_number is required.
authcode
String required

MAC code for the payment. It is calculated using HMAC-SHA256. HMAC implementations exist for most popular programming languages.

Sub-merchant private key is used as the secret key and the message is calculated from the values of the following fields:

  • api_key
  • token OR order_number

Fields are joined with '|' character and they are appended in the specified order. The authcode must always be in UPPERCASE.

Example request body
{
  "version": "w3.1",
  "api_key": "15-ku74gbued",
  "token": "kufoaskjhigrmkn45p2356n34",
  "authcode": "F54E61647170963E3CE338EABF8410078817D0B3A516..."
}

 Payment status return

response type HTTP JSON

 Payment status return JSON object fields

Key Details
result Result code.
Value Explanation
0Success
1Validation error or invalid token.
2Payment failed.
3The payment is in incoming state and has not been finished by the customer. Try again later.
4The status of the payment is reversed (authorized and then cancelled by the merchant).
10Maintenance break.
settled Only set when the transaction was successful (result = 0). Defines whether the transaction was settled (e.g. billed from the credit card) or was the payment only authorized.
Value Explanation
0 authorized / not settled
1 settled
source
Source object

Source object.

Example response body
{
  "result": 0,
  "settled": 1,
  "source": {
    "object": "card",
    "last4": "4242",
    "brand": "Visa",
    "exp_year": 2018,
    "exp_month": 5,
    "card_token": "sfasdfhmn39275y249035bhdfxslg",
    "card_verified": "Y",
    "card_country": "FI",
    "client_ip_country": "FI",
    "error_code": null
  }
}

 Capture payment request

request url https://www.vismapay.com/pbwapi/capture

request type HTTP JSON

Capture payment

 Capture payment request fields

Key Details
version
String required
Version number. Should be w3.1 (or wm3.1 / wp3.1 for channel).
api_key
String required
The sub-merchant api key which is associated with the used private key. The sub-merchant api key is listed in the sub-merchants page in the merchant UI.
order_number
String required
Order number of the payment to settle.
authcode
String required

MAC code for the payment. It is calculated using HMAC-SHA256. HMAC implementations exist for most popular programming languages.

Sub-merchant private key is used as the secret key and the message is calculated from the values of the following fields:

  • api_key
  • order_number

Fields are joined with '|' character and they are appended in the specified order. The authcode must always be in UPPERCASE.

Example request
{
  "version": "w3.1",
  "api_key": "15-ku74gbued",
  "order_number": "webshop_stuff-1234567",
  "authcode": "F54E61647170963E3CE338EABF8410078817D0B3A516..."
}

 Capture payment return

response type HTTP JSON

 Capture payment return JSON object fields

Key Details
result Result code.
Value Explanation
0Success
1Validation Error
2Payment cannot be captured. Authorization was cancelled or card cannot be billed.
3Transaction for given order_number was not found.
10Maintenance break.
Example response body
{
  "result": 0
}

 Cancel payment request

request url https://www.vismapay.com/pbwapi/cancel

request type HTTP JSON

Cancel payment

 Cancel payment request fields

Key Details
version
String required
Version number. Should be w3.1 (or wm3.1 / wp3.1 for channel).
api_key
String required
The sub-merchant api key which is associated with the used private key. The sub-merchant api key is listed in the sub-merchants page in the merchant UI.
order_number
String required
Order number of the payment to cancel.
authcode
String required

MAC code for the payment. It is calculated using HMAC-SHA256. HMAC implementations exist for most popular programming languages.

Sub-merchant private key is used as the secret key and the message is calculated from the values of the following fields:

  • api_key
  • order_number

Fields are joined with '|' character and they are appended in the specified order. The authcode must always be in UPPERCASE.

Example request
{
  "version": "w3.1",
  "api_key": "15-ku74gbued",
  "order_number": "webshop_stuff-1234567",
  "authcode": "F54E61647170963E3CE338EABF8410078817D0B3A516..."
}

 Cancel payment return

response type HTTP JSON

 Cancel payment return JSON object fields

Key Details
result Result code.
Value Explanation
0Success
1Validation Error
2Payment cannot be cancelled. Payment is not in "Authorized" -state.
3Transaction for given order_number was not found.
10Maintenance break.
Example response body
{
  "result": 0
}

 Get card token request

request url https://www.vismapay.com/pbwapi/get_card_token

request type HTTP JSON

Get a card token

 Get card token request fields

Key Details
version
String required
Version number. Should be w3.1 (or wm3.1 / wp3.1 for channel).
api_key
String required
The sub-merchant api key which is associated with the used private key. The sub-merchant api key is listed in the sub-merchants page in the merchant UI.
card_token
String required
Card token.
authcode
String required

MAC code for the payment. It is calculated using HMAC-SHA256. HMAC implementations exist for most popular programming languages.

Sub-merchant private key is used as the secret key and the message is calculated from the values of the following fields:

  • api_key
  • card_token

Fields are joined with '|' character and they are appended in the specified order. The authcode must always be in UPPERCASE.

Example request
{
  "version": "w3.1",
  "api_key": "15-ku74gbued",
  "card_token": "sfasdfhmn39275y249035bhdfxslg",
  "authcode": "2B221E1C5F732787E1528EF04D4571CF85EF08EBAB4E..."
}

 Get card token return

response type HTTP JSON

 Get card token return JSON object fields

Key Details
result Result code.
Value Explanation
0Success
1Validation Error
3card_token not found.
10Maintenance break
source
Source object

Source object. Returned if result was successful.

Example response body
{
  "result": 0,
  "source": {
    "object": "card",
    "last4": "4242",
    "brand": "Visa",
    "exp_year": 2018,
    "exp_month": 5,
    "card_token": "sfasdfhmn39275y249035bhdfxslg"
  }
}

 Delete card token request

request url https://www.vismapay.com/pbwapi/delete_card_token

request type HTTP JSON

Delete a card token

 Delete card token request fields

Key Details
version
String required
Version number. Should be w3.1 (or wm3.1 / wp3.1 for channel).
api_key
String required
The sub-merchant api key which is associated with the used private key. The sub-merchant api key is listed in the sub-merchants page in the merchant UI.
card_token
String required
Card token.
authcode
String required

MAC code for the payment. It is calculated using HMAC-SHA256. HMAC implementations exist for most popular programming languages.

Sub-merchant private key is used as the secret key and the message is calculated from the values of the following fields:

  • api_key
  • card_token

Fields are joined with '|' character and they are appended in the specified order. The authcode must always be in UPPERCASE.

Example request
{
  "version": "w3.1",
  "api_key": "15-ku74gbued",
  "card_token": "sfasdfhmn39275y249035bhdfxslg",
  "authcode": "2B221E1C5F732787E1528EF04D4571CF85EF08EBAB4E..."
}

 Delete card token return

response type HTTP JSON

 Delete card token return fields

Key Details
result

Result code

Value Explanation
0Success
1Failed
10Maintenance break
Example response
{
  "result": 0
}

 Get payment request

request url https://www.vismapay.com/pbwapi/get_payment

request type HTTP JSON

Retrieve information about a specific payment. Get payment request is done from backend to Visma Pay API.

 Get payment request fields

Key Details
version
String required
Version number. Should be w3.1 (or wm3.1 / wp3.1 for channel).
api_key
String required
The sub-merchant api key which is associated with the used private key. The sub-merchant api key is listed in the sub-merchants page in the merchant UI.
order_number
String required
The order number of the payment.
authcode
String required

MAC code for the payment. It is calculated using HMAC-SHA256. HMAC implementations exist for most popular programming languages.

Sub-merchant private key is used as the secret key and the message is calculated from the values of the following fields:

  • api_key
  • order_number

Fields are joined with '|' character and they are appended in the specified order. The authcode must always be in UPPERCASE.

Example request body
{
  "version": "w3.1",
  "api_key": "15-ku74gbued",
  "order_number": "test_order_1",
  "authcode": "ACA7E762BA1138F0C5C8561599D72409055A16701B901..."
}

 Get payment return

response type HTTP JSON

 Get payment return JSON object fields

Key Details
result Result code.
Value Explanation
0Success
1Validation error or invalid request.
2Payment not found.
10Maintenance break.
payment
Payment object

Payment object. Returned if result was successful.

errors
Array

Array containing explanations of validation errors. Only returned if there have been specific validation errors.

 Payment object

Key Details
id
Integer
ID of the payment in Visma Pay's system.
amount
Integer
Total amount of the payment in fractional monetary units e.g. 1€ = 100.
currency
String
See currencies for more information.
order_number
String
Order number of the payment defined by the merchant.
source
Source object
Source object.
created_at
String
Date when the payment was created. Returned in format: "YYYY-MM-DD HH-MM-SS" and in UTC-time.
status
Integer
Current status of the payment. Possible values are:
Value Explanation
0 Incoming - payment is still in progress.
1 Authorized - payment has been authorized but it hasn't been captured.
2 Authorization failed - payment was not completed succesfully or it was declined.
3 Validation failed - payment has failed due to validation error.
4 Settled - payment has been completed succesfully.
5 Paid - payment has been completed succesfully and it has been paid to the merchant.
14 Reversed - authorization of a transaction has been canceled.
15 Forwarded Paid - payment has been completed succesfully and it will be paid to the merchant by the provider of the payment method.
refund_type
String
Type of refund that can be done for this payment. This value is used in the Refund API. Possible values are:
Value Explanation
instant Refund can be done instantly.
email Refund needs to be confirmed by the customer.
customer
Customer object
Payment customer object
payment_products
Array of payment product objects
Array of Payment product objects
refunds
Array of payment refund objects
Array of Refund objects

 Refund object

Key Details
refund_id
Integer
ID of the refund in Visma Pay's system.
amount
Integer
Total negative amount of the refund in fractional monetary units e.g. -1€ = -100.
order_number
String
Order number of the payment defined by the merchant.
created_at
String
Date when the payment was created. Returned in format: "YYYY-MM-DD HH-MM-SS" and in UTC-time.
status
Integer
Current status of the refund. Possible values are:
Value Explanation
6 Refund requested - refund has been requested, but it is in progress.
7 Refund requested (by the merchant) - refund has been requested, but it hasn't been accepted.
8 Refund requested (by the customer) - refund has been requested, but it hasn't been accepted.
9 Refund accepted - refund has been completed succesfully.
10 Refund accepted - refund has been completed succesfully and the amount has been deducted from the merchant.
11 Refund rejected - refund failed.
12 Refund rejected by merchant - merchant has declined a refund request sent by a customer.
13 Refund rejected by customer - customer has declined a refund request sent by the merchant.
16 Forwarded Refunded - refund has been completed succesfully and it will be deducted from the merchant by the provider of the payment method.
payment_products
Array of payment product objects
Array of Payment product objects that were refunded in this refund. This array will be empty if no products were defined in the refund request, .

 Payment product object

Key Details
id
String
Product's id provided by the merchant in the payment token request.
product_id
Integer
Product's id in Visma Pay's system. Can be used for refunding by using our API.
title
String
Product's name.
count
Integer
Amount of products.
tax
Integer
Product's tax percent. Returned as integer without %-sign e.g 24% = 24.
pretax_price
Integer
Product's pretax price. Can also be negative if type is 4 (discount).
price
Integer
Product's price. Can also be negative if type is 4 (discount).
type
Integer
Product's type. Value 1 indicates normal product row. Value 2 indicates shipment costs. Value 3 indicates handling costs. Value 4 indicates discount.
merchant_id
Integer
ID of the merchant's sub merchant id that is attached to the channel. Only returned for Channel payments
cp
String
Provision level ID for the product. Only returned for Channel payments.

 Payment customer object

Key Details
firstname
String
Customer's first name.
lastname
String
Customer's last name.
email
Email
Customer's email address.
address_street
String
Customer's street address.
address_city
String
Customer's city address.
address_zip
String
Customer's zip code.
address_country
String
Customer's country.
Example of a successful response body
{
  "result": 0,
  "payment": {
    "id": 123,
    "amount": 562,
    "currency": "EUR",
    "order_number": "test_order_1",
    "created_at": "2018-09-12 08:30:22",
    "status": 4,
    "refund_type": "email",
    "source": {
      "object": "e-payment",
      "brand": "Nordea"
    },
    "customer": {
      "firstname": "Test",
      "lastname": "Person",
      "email": "test.person@vismapay.com",
      "address_street": "",
      "address_city": "",
      "address_zip": ""
    },
    "payment_products": [{
      "id": "as123",
      "product_id": 1123,
      "title": "Product 1",
      "count": 2,
      "pretax_price": 100,
      "tax": 24,
      "price": 124,
      "type": 1
    },
    {
      "id": "sku123",
      "product_id": 1124,
      "title": "Product 2",
      "count": 1,
      "pretax_price": 100,
      "tax": 14,
      "price": 114,
      "type": 1
    },
    {
      "id": "ab1",
      "product_id": 1125,
      "title": "Shipping",
      "count": 1,
      "pretax_price": 200,
      "tax": 0,
      "price": 200,
      "type": 2
    }],
    "refunds": [{
      "id": 123,
      "amount": -114,
      "created_at": "2018-09-12 09:09:01",
      "order_number": "test_order_1",
      "status": 9,
      "payment_products": [{
        "id": "sku123",
        "product_id": 1124,
        "title": "Product 2",
        "count": 1,
        "pretax_price": 100,
        "tax": 14,
        "price": 114,
        "type": 1
      }]
    }]
  }
}

 Get refund request

request url https://www.vismapay.com/pbwapi/get_refund

request type HTTP JSON

Retrieve information about a specific refund. Get refund request is done from backend to Visma Pay API.

 Get refund request fields

Key Details
version
String required
Version number. Should be w3.1 (or wm3.1 / wp3.1 for channel).
api_key
String required
The sub-merchant api key which is associated with the used private key. The sub-merchant api key is listed in the sub-merchants page in the merchant UI.
refund_id
Integer required
Transaction id of the refund.
authcode
String required

MAC code for the payment. It is calculated using HMAC-SHA256. HMAC implementations exist for most popular programming languages.

Sub-merchant private key is used as the secret key and the message is calculated from the values of the following fields:

  • api_key
  • refund_id

Fields are joined with '|' character and they are appended in the specified order. The authcode must always be in UPPERCASE.

Example request body
{
  "version": "w3.1",
  "api_key": "15-ku74gbued",
  "refund_id": "123",
  "authcode": "ECA7E762BA1138F0C5CB561599D72409066A16701B901..."
}

 Get refund return

response type HTTP JSON

 Get refund return JSON object fields

Key Details
result Result code.
Value Explanation
0Success
1Validation error or invalid request.
2Refund not found.
10Maintenance break.
refund
Refund object

Refund object. Returned if result was successful.

errors
Array

Array containing explanations of validation errors. Only returned if there have been specific validation errors.

Example of a successful response body
{
  "result": 0,
  "refund": {
    "refund_id": 123,
    "amount": -114,
    "created_at": "2018-09-12 09:09:01",
    "order_number": "test_order_1",
    "status": 9,
    "payment_products": [
      {
        "id": "sku123",
        "product_id": 1124,
        "title": "Product 2",
        "count": 1,
        "pretax_price": 100,
        "tax": 14,
        "price": 114,
        "type": 1
      }
    ]
  }
}

 Refund payment request

request url https://www.vismapay.com/pbwapi/create_refund

request type HTTP JSON

Refund payment. Please contact our support if you want to use this feature.

Payment can be refunded if the status of the payment is 4 (Settled), 5 (Paid) or 15 (Forwarded Paid). Status of the payment is returned in the Get payment request

 Refund payment request fields

Key Details
version
String required
Version number. Should be w3.1 (or wm3.1 / wp3.1 for channel).
api_key
String required
The sub-merchant api key which is associated with the used private key. The sub-merchant api key is listed in the sub-merchants page in the merchant UI.
order_number
String required
Order number of the payment to refund.
email
Email
An email address where a refund request is sent. Required if a refund can not be processed instantly.
amount
Integer
Amount to be refunded. Either amount or products is required.
products
Array of refund product objects

Products to be refunded. Either amount or products is required.

If a payment was made using wm3.1 (channel) then products are always required as refunding by only amount is not possible.

You can get product ids by using the get payment details request.

notify_url
Url

This URL is called after a refund has been marked to final state. The request is done by Visma Pay server so customer browser session doesn't exist. The request is done couple of minutes after the refund has been processed.

The interface is expecting a HTTP status code 20x if the query is caught. The notify request is retried up to 3 times. Only URLs with protocol default ports (https:443, http:80) are supported.

See Refund payment notify return for the returned fields.

authcode
String required

MAC code for the payment. It is calculated using HMAC-SHA256. HMAC implementations exist for most popular programming languages.

Sub-merchant private key is used as the secret key and the message is calculated from the values of the following fields:

  • api_key
  • order_number

Fields are joined with '|' character and they are appended in the specified order. The authcode must always be in UPPERCASE.

 Refund product object

Key Details
product_id
Integer required
The id of the product in Visma Pay's system. Retuned in the get payment details request.
count
Integer required
Count of products to be refunded.
Example request (with amount)
{
  "version": "w3.1",
  "api_key": "15-ku74gbued",
  "order_number": "webshop_stuff-1234567",
  "amount": 5000,
  "authcode": "F54E61647170963E3CE338EABF8410078817D0B3A516..."
}
Example request (with products)
{
  "version": "w3.1",
  "api_key": "15-ku74gbued",
  "order_number": "webshop_stuff-1234567",
  "notify_url": "https://test.shop.com/return/",
  "authcode": "F54E61647170963E3CE338EABF8410078817D0B3A516...",
  "products": [
    {
      "product_id": 9532,
      "count": 1
    },
    {
      "product_id": 9534,
      "count": 2
    }
  ]
}

 Refund payment return

response type HTTP JSON

 Refund payment return JSON object fields

Key Details
result Result code.
Value Explanation
0Success
1Error
10Maintenance break.
type

The type of the refund. Possible values are:

  • instant the refund is immediately processed
  • email a confirmation email is sent to the customer and customer must accept it
refund_id

The id of the refund.

refund_url

The url of the refund form where a customer inputs IBAN. This is sent to the customer in the email. Only returned if type is email.

errors

Array containing explanations of errors. Only returned if there have been specific errors.

Example response body
{
  "result": 0,
  "type": "instant",
  "refund_id": 2587411
}

 Refund payment notify return

response type HTTP GET

Notify-request is done to the notify_url specified in the Refund payment request.

 Notify-request fields

Key Details
RETURN_CODE Result code.
Value Explanation
0Refund has been accepted
1Refund has been rejected
REFUND_ID

The id of the refund.

AUTHCODE

MAC code for the payment. It is calculated using HMAC-SHA256. HMAC implementations exist for most popular programming languages.

Sub-merchant private key is used as the secret key and the message is calculated from the values of the following fields:

  • RETURN_CODE
  • REFUND_ID

Fields are joined with '|' character and they are appended in the specified order. The authcode must always be in UPPERCASE.

Example
GET https://test.shop.com/return/?RETURN_CODE=0&REFUND_ID=2587411&AUTHCODE=C250B657F55442415F5F2422D20453D029E381E17EF665BA24FB1109AA045A71 HTTP/1.1

 Cancel refund request

request url https://www.vismapay.com/pbwapi/cancel_refund

request type HTTP JSON

Cancel a refund request. Only refunds where type is email and are not accepted by a customer can be cancelled.

 Refund payment request fields

Key Details
version
String required
Version number. Should be w3.1 (or wm3.1 / wp3.1 for channel).
api_key
String required
The sub-merchant api key which is associated with the used private key. The sub-merchant api key is listed in the sub-merchants page in the merchant UI.
refund_id
Integer required
The id of the refund. Returned in the refund payment request.
authcode
String required

MAC code for the payment. It is calculated using HMAC-SHA256. HMAC implementations exist for most popular programming languages.

Sub-merchant private key is used as the secret key and the message is calculated from the values of the following fields:

  • api_key
  • refund_id

Fields are joined with '|' character and they are appended in the specified order. The authcode must always be in UPPERCASE.

Example request
{
  "version": "w3.1",
  "api_key": "15-ku74gbued",
  "refund_id": 235468,
  "authcode": "F54E61647170963E3CE338EABF8410078817D0B3A516..."
}

 Cancel refund return

response type HTTP JSON

 Cancel refund request return JSON object fields

Key Details
result Result code.
Value Explanation
0Success
1Validation Error
10Maintenance break.
errors

Array containing explanations of validation errors. Only returned if there have been specific validation errors.

Example response body
{
  "result": 0
}