Payment Provider Specific Notes

Credit Card Acquirers

Not supported

Shift4

Verify card

Over refund
Nets/Teller

Credit

Over refund
AltaPay

Credit

Over refund
Elavon US

Credit

Over refund

Callback pages in use

  • Form
  • Redirect (3D Secure)
  • Verify order
  • OK
  • Fail
  • Notification (Chargebacks)

Invoice payments

The following extra parameters must be present when authorizing:

  • Customer information (name, address, phone, e-mail & country)
  • Order lines, which must include
    • Description
    • itemId
    • quantity
    • unitPrice
    • taxPercent/taxAmount
    • goodsType

In case of a partial capture or refund, updated order lines must be passed. The updated order lines must relate to the original set of order lines.

In some cases, Klarna will flag a reservation as pending. This happens when it needs to undergo manual review. A response will be given within 24 hours. We support this via the open/notification option.

There are two options available:

  • Klarna Invoice is a single-instalment version where the customer receives the invoice via e-mail and must pay it within 14 days.
  • Klarna Account gives the customer the option to pay for the product for over several instalments.

The merchant is not affected by the option chosen. With both options, the merchant will receive the money from Klarna after a given set of days (14 days is standard).

Both Klarna options have some basic frontend requirements:

  • Klarna's logotypes (invoice and/or part payment) must be visible on the start page
  • Klarna's logotypes must be in place next to the payment options in the checkout
  • The specific Klarna decline message must be shown to the customer

There are currently the following country specific requirements:

  • Germany: The customer must actively consent (via a checkbox) to a specific text. This is needed for both payment options, and is required due to German data protection laws. The text should be generated based on a snippet from Klarna. You can locate it here: http://developers.klarna.com/en/dynamic-store-assets/consumer-terms-conditions
    Choose Germany as country, EID is not needed.
  • Netherlands: If the account option is offered, Dutch law requires you to show a banner which warns the customer that it costs money to borrow money.
    The banner has the following requirements:
    • It must span the entire width of the part payment
    • It must be at least 10 percent of the entire advertisement
    • The text must be at least 7pt high

    The banner and more information can be located here: https://www.afm.nl/nl-nl/professionals/onderwerpen/informatieverstrekking/kredietwaarschuwing-iv
    (The page is in Dutch but Google translate can be used.)

  • Norway: Has some very strict requirements when it comes to Klarna account. There is detailed information here.
    Klarna Campaign is not relevant at the moment, since it is a special product offered.
  • Sweden: Goods cannot be sent to an address other than the public registered address. Klarna performs address verification for Swedish customers. In case the address varies from the one provided by the customer, the customer needs to approve the updated address before it is accepted. The updated address is returned in our API via the registered address parameter. You also have the option to have the terminal set up so the transaction is declined in case of a mismatch if requested. This means that Sweden will work the same way as other countries.

Refunds

Refunds spanning multiple captures are not supported. These must be refunded individually, so that each "fits" within an existing capture.

Goodwill refunds can be used to refund an arbitrary amount independent of the existing order lines. To do this, submit a refund for the amount to refund (including tax) with exactly one order line. That order line must have:

  • goodsType of "refund"
    • The goodsType "refund" must not be used in any other case..
  • quantity of "1"
  • unitPrice matching the refund amount
  • description
  • taxAmount as needed

You must also provide the mandatory parameter itemId although its value will be ignored.

Not supported

  • Over refund
  • Update of order lines, e.g. adding products
  • Surcharging
  • Credit
  • Subscriptions

Callback pages in use

  • Form
  • Verify order
  • OK
  • Fail
  • Open (Pending)
  • Notification (Pending clarification)

The following extra parameters must be present when capturing:

  • Customer information (name, address, phone & e-mail)
  • Order lines, which must include:
  • Description
  • itemId
  • quantity
  • unitPrice
  • taxPercent/taxAmount

In case of a partial capture or refund, updated order lines must be passed. Note that the updated order lines must relate to the original set of order lines. If you want to generate the invoice yourself, you must utilize the API/getInvoiceText call after the capture to get necessary details for the invoice.

The invoice has the following requirements:

  • The mandatory text from getInvoiceText must be printed clearly on the invoice.
  • If you do not supply the invoice number, the invoice number must be the one provided by getInvoiceText.
  • If the account option is enabled you need to print the account offer text, login info and minimum to pay amount provided by getInvoiceText.
  • Instead of the login text supplied you can choose to write your own, but you need to write the user name, password and link to PayByBill's login page provided by getInvoiceText.
  • If you want to have Giro payment available as well, you need to print the relevant label at the bottom. The OCR number is supplied in the getInvoiceText. The other parameters can be requested by writing to support@altapay.com.
  • The customer number must be the one supplied by provided by getInvoiceText.

In Finland and Norway the items must be shipped to the address returned by PayByBill (this will in most cases be the one you get from the customer). The parameter “RegisteredAddress” contains the address that PayByBill have in their records. In Denmark, Sweden and Germany, you can send the items to an address other than the one returned by PayByBill. This however needs to be negotiated with PayByBill for each country.

Not supported:

  • Over refund
  • Update of order lines, e.g. adding products
  • Surcharging
  • Credit
  • Subscriptions
  • Acquirer based reconciliation files

Callback pages in use:

  • Form
  • Verify order
  • OK
  • Fail
  • Order number will be suffixed with "---RANDOM ID" in order to ensure uniqueness of orders in the ViaBill system.
  • order_lines is optional, but we recommend to send it
  • Implementation of price tags is mandatory for ViaBill Xtra (credit limit between 2001 – 10 000 DKK) and highly recommended for ViaBill Free (credit limit 1 – 2000 DKK). A price tag is additional information, which is visible for the consumer during the shopping flow. The price tag informs the consumer about if any fees appear, instalment amount etc.
  • Order confirmation/receipt from the webshop should not contain any bank information.
  • Other logos and visual identity can be downloaded from here. (cf. Terms & Conditions)
  • It is possible that a notification will be sent before we call callback-OK/callback-FAIL.

Not supported

  • Over refund
  • Surcharging
  • Credit
  • Subscriptions

Callback pages in use

  • Form
  • OK
  • Fail
  • Notification

Limitations

Unique order number per merchant

Refunds are done manually by contacting Santander. Pressing refund in our system will automatically send an email to them. Invoice type requires order lines to work. Total sum of order lines should match total amount. For Here And Now / Here And Now Student order lines are optional. The <ReasonCode> tag can be used to see who an open payment is waiting for (possible values).

Not supported

  • Over refund
  • Surcharging
  • Credit
  • Subscriptions
  • Acquirer based reconciliation files

Callback pages in use

  • Form
  • OK (not used as customer should sign documents after filling the form)
  • Fail
  • Open (Pending)
  • Notification

Wallet solutions

  • The notification callback is triggered on all events.
  • After 29 days PayPal will cancel the authorization and you will not be able to capture it.
  • After 3 days the authorization will expire. You will still be able to capture the transaction, but there's a higher risk of having the capture declined, e.g. due to insufficient funds.
  • If you performed partial captures, you will not be able to refund a higher amount than one of the partial captures. In such a case you will need to break the refund into parts lower than the maximum capture. E.g. if you capture 40+30 and want to refund 60, you'll need to first refund 40 then 20.
  • When passing in US addresses, the region field should be passed in using a 2 character ISO abbreviation. See https://en.wikipedia.org/wiki/ISO_3166-2:US

Not supported

  • Over refund
  • Surcharging
  • Credit
  • Subscriptions

Callback pages in use

  • Form
  • Verify order
  • OK
  • Fail
  • Open (Pending)
  • Notification

Credit card wallet solutions

The customer can decide to choose another shipping address inside the MasterPass website. This is returned in the registered address parameters. The option for the customer to choose this can be disabled. Please contact us for more information.

Not supported

  • Over refund
  • Surcharging
  • Credit
  • Subscriptions

Callback pages in use

Please check under the relevant acquirer

  • Only allows payments in DKK
  • Only accepts orderids of 50 characters or less

Not supported

  • Credit
  • Subscriptions

Callback pages in use

  • Form callback page is not shown to the user
  • Please check under the relevant credit card acquirer about additional callbacks

Merchant needs to implement Javascript in order to accept ApplePay

Not supported

  • Over refund
  • Surcharging
  • Credit
  • Subscriptions

Callback pages in use

No callbacks.

Orderids are truncated if longer than 30 characters

E-payment solutions

There's a risk that the customer doesn't return after finalizing the payment at Sofort. In this case the payment will be in an incomplete state (epayment_initialized).

Not supported

  • Over refund
  • Surcharging
  • Credit
  • Subscriptions
  • Reservations (automatically changes to paymentAndCapture)
  • Multiple captures
  • Acquirer based reconciliation files

Callback pages in use

  • Form
  • Verify order
  • OK
  • Fail

There's a risk that the customer doesn't return after finalizing the payment at Paysera. In this case the payment will be in an incomplete state (epayment_initialized).

Not supported

  • Over refund
  • Surcharging
  • Credit
  • Subscriptions
  • Reservations (automatically changes to paymentAndCapture)
  • Multiple captures
  • Acquirer based reconciliation files

Callback pages in use

  • Form
  • Verify order
  • OK
  • Fail
  • There's a risk that the customer doesn't return after finalizing the payment at Przelewy24. In this case the payment will be in an incomplete state (epayment_initialized).
  • Some of the banks in the Przelewy24 network support only offline transfers which means the customer needs to go to a bank to perform the actual transfer. It can therefore take several days from when the payment is initiated until the transfer is verified.

The following extra parameters must be present when making a payment request:

  • Customer information (email address)

Not supported

  • Over refund
  • Surcharging
  • Credit
  • Subscriptions
  • Reservations (automatically changes to paymentAndCapture)
  • Multiple captures
  • Acquirer based reconciliation files

Callback pages in use

  • Form
  • Verify order
  • OK
  • Fail
  • Open (Pending)
  • Notification

There's a risk that the customer doesn't return after finalizing the payment at the bank. In this case the payment will be in an incomplete state (epayment_initialized)

Not supported

  • Over refund
  • Multiple refunds
  • Surcharging
  • Credit
  • Subscriptions
  • Reservations (automatically changes to paymentAndCapture)
  • Multiple captures
  • Acquirer based reconciliation files

There's a risk that the customer doesn't return after finalizing the payment at the bank. In this case the payment will be in an incomplete state (epayment_initialized)

Not supported

  • Over refund
  • Multiple refunds
  • Surcharging
  • Credit
  • Subscriptions
  • Reservations (automatically changes to paymentAndCapture)
  • Multiple captures
  • Acquirer based reconciliation files

Callback pages in use

  • Form
  • Verify order
  • OK
  • Fail
  • Open (Pending)
  • Notification

There's a risk that the customer doesn't return after finalizing the payment at the bank. In this case the payment will be in an incomplete state (epayment_initialized)

Not supported

  • Refund
  • Surcharging
  • Credit
  • Subscriptions
  • Reservations (automatically changes to paymentAndCapture)
  • Multiple captures
  • Acquirer based reconciliation files

There's a risk that the customer doesn't return after finalizing the payment at the bank. In this case the payment will be in an incomplete state (epayment_initialized)

Not supported

  • Refund
  • Surcharging
  • Credit
  • Subscriptions
  • Reservations (automatically changes to paymentAndCapture)
  • Multiple captures
  • Acquirer based reconciliation files

There's a risk that the customer doesn't return after finalizing the payment at the bank. In this case the payment will be in an incomplete state (epayment_initialized)

Not supported

  • Over refund
  • Multiple refunds
  • Surcharging
  • Credit
  • Subscriptions
  • Reservations (automatically changes to paymentAndCapture)
  • Multiple captures
  • Acquirer based reconciliation files

There's a risk that the customer doesn't return after finalizing the payment at the bank. In this case the payment will be in an incomplete state (epayment_initialized)

Not supported

  • Refund
  • Surcharging
  • Credit
  • Subscriptions
  • Reservations (automatically changes to paymentAndCapture)
  • Multiple captures
  • Acquirer based reconciliation files

There's a risk that the customer doesn't return after finalizing the payment at the bank. In this case the payment will be in an incomplete state (epayment_initialized)

Not supported

  • Refund
  • Surcharging
  • Credit
  • Subscriptions
  • Reservations (automatically changes to paymentAndCapture)
  • Multiple captures
  • Acquirer based reconciliation files

There's a risk that the customer doesn't return after finalizing the payment at the bank. In this case the payment will be in an incomplete state (epayment_initialized)

Not supported

  • Refund
  • Surcharging
  • Credit
  • Subscriptions
  • Reservations (automatically changes to paymentAndCapture)
  • Multiple captures
  • Acquirer based reconciliation files

Due to EU directives, you need to get the customers approval of the debit. This is referred to as a direct debit mandate. A reference of this approval is send to the customers bank. The id is a sanitized version of the order id. More information about the mandate can be found here: EU mandate information

Not supported

  • Over refund
  • Surcharging
  • Credit
  • Multiple captures
  • Acquirer based reconciliation files

iDEAL

There's a risk that the customer doesn't return after finalizing the payment at the respective bank. In this case the payment will be in an incomplete state (epayment_initialized). An hourly job checks all incomplete transactions. In case the transaction was finalized a notification is send.

Not supported

  • Over refund
  • Surcharging
  • Credit
  • Subscriptions
  • Reservations (automatically changes to paymentAndCapture)
  • Multiple captures
  • Acquirer based reconciliation files

Callback pages in use

  • Form
  • Verify order
  • OK
  • Open
  • Fail
  • Notification

There's a risk that the customer doesn't return after finalizing the payment at the respective bank. In this case the payment will be in an incomplete state (epayment_initialized). An hourly job checks all incomplete transactions. In case the transaction was finalized a notification is send.

Not supported

  • Over refund
  • Surcharging
  • Credit
  • Subscriptions
  • Reservations (automatically changes to paymentAndCapture)
  • Multiple captures
  • Acquirer based reconciliation files

Callback pages in use

  • Form
  • Verify order
  • OK
  • Open
  • Fail
  • Notification

There's a risk that the customer doesn't return after finalizing the payment at the respective bank. In this case the payment will be in an incomplete state (epayment_initialized). An hourly job checks all incomplete transactions. In case the transaction was finalized a notification is send.

Not supported

  • Over refund
  • Surcharging
  • Credit
  • Subscriptions
  • Reservations (automatically changes to paymentAndCapture)
  • Multiple captures
  • Acquirer based reconciliation files

Callback pages in use

  • Form
  • Verify order
  • OK
  • Open
  • Fail
  • Notification

Gift Cards

Supported

  • Issue new virtual gift card (with requested balance)
  • Query Gift Card
  • Credit
  • Reserve
  • Release
  • Capture
  • Refund (including over refund)

Not supported

  • Multiple captures on same reservation
  • Update of order lines, e.g. adding products
  • Surcharging
  • Subscriptions
  • Verify card

Callback pages in use

  • Form
  • Verify order
  • OK
  • Fail

Supported

  • Query Gift Card
  • Credit
  • Sale (Reserve and Capture)
  • Refund

Not supported

  • Reserve
  • Capture
  • Release
  • Issue new virtual gift card (with requested balance)
  • Multiple captures on same reservation
  • Update of order lines, e.g. adding products
  • Surcharging
  • Subscriptions
  • Verify card

Callback pages in use

  • Form
  • Verify order
  • OK
  • Fail

Mobile solutions

Not supported

  • Over refund
  • Surcharging
  • Credit
  • Subscriptions
  • Acqurier based reconcilation files
  • Reservations

Callback pages in use

  • Form
  • OK
  • Fail
  • Notification

It is possible to style the mobile payment form, to only show parts of it, or change the text, as shown below.

// To only show mobile app button by removing the phone number, input
form#Mobile {
   display:none !important;
}
// Or vice versa
form#MobileOnApp {
   display:none !important;
}
// If you wish to show both, but change the text between them, you could do so like this
.AltaPayMobileInputOptionOr {
   display:none;
}
#MobileOnApp::after {
   content: 'Alternatively';
}

We check whether the user is on a mobile device by default. If you manually hide form#Mobile, form#MobileOnApp will be forced to be shown even though the user is not using a mobile device.