VerifyCard as unscheduled Charges

For backwards compatibility, it is possible to use the verifyCard to set up an unscheduled charges agreement.

Setup the Agreement

You can set the Agreement by sending:

Please make sure you store both the paymentId and the credit card token in your system.

Charge the Agreement

You can charge the agreement by sending

  • /reservation request

    This will charge the subscription right away or, in case the payment should be authenticated, it will return a redirect response where the customer should be redirected in order to authenticate the payment.

    Redirect response example: 
    <?xml version="1.0" encoding="utf-8" ?>
<APIResponse version="20170228">
    <Header>
        <Date>2021-11-16T08:19:10+00:00</Date>
        <Path>API/reserveSubscriptionCharge</Path>
        <ErrorCode>0</ErrorCode>
        <ErrorMessage/>
    </Header>
    <Body>
        <Result>Redirect</Result>
        <RedirectResponse>
          <Url>https://testgateway.altapaysecure.com/eCommerce/API/3ds/737f04f7-2eeb-46c6-b003-a1a623cd2443/input?callback=https%3A%2F%2Ftestgateway.altapaysecure.com%2FeCommerce%2FAPI%2FValidatePaymentAuthenticationCollect3DSDataCallback%2Fdf176859-e715-4104-b101-6841ce14a042</Url>
          <Method>GET</Method>
          <Data/>
        </RedirectResponse>
    </Body>
</APIResponse>

  • createPaymentRequest

    This will redirect to the requestForm page where the customer will have to complete the CVC/CVC2 and then submit the payment.

Below are described the

Parameter

Description

Type

 Mandatory

terminal

The terminal determines the payment method and currency. For more information, see AltaPay's Payment Gateway. This is the title of your terminal, found under Home > Terminal Settings in the Merchant Interface. You can use variables in the terminal parameter. For example, if you want to call My EUR Terminal, you can set the terminal parameter value to 'My {currency} Terminal', where {currency} references the value of the currency parameter.

string

Yes

shop_orderid

This is the internal ID of the order in your webshop. In most integrations, you can use the same order ID for up to four orders. For PayPal, MobilePay and Vipps payments, you can only use it for a singe successful transaction. The shop_orderid value is posted back to you, so you know the order to which the payment refers.

[a-zA-Z0-9-]{1,100}

Yes

amount

This is the payment amount. If you are setting up a subscription, it is the default amount for each capture. You must use a dot as the decimal separator, and the amount can have maximum 2 decimals.

float

Yes

currency

This is the payment currency. It must be specified in an ISO-4217 format, either using the 3-digit numeric code, or the 3-letter character code. For more information about ISO-4217 currency codes, see https://en.wikipedia.org/wiki/ISO_4217.

[0-9]{3} or

[A-Z]{3}

Yes

type

This is the authorization type. For more information, see Payment request types:

  • payment (default)
  • paymentAndCapture

String

Yes

ccToken / credit_card_token

This is the credit card token from the verifyCard payment, if this is supplied in the createPaymentRequest then the credit card will be pre-filed out with the card number and expiration month and year. ccToken and credit_card_token can both be used when charge the agreement by using /createPaymentRequest request. Only credit_card_token can be used when charge the agreement by using /reservation request.

String

Yes

agreement[id]

This is the id of the verifyCard payment.

String

Yes

agreement[unscheduled_type]

Possible values:

  • incremental (Notes: No cardholder authentication required)
  • resubmission (Notes: No cardholder authentication required)
  • delayedCharges (Notes: No cardholder authentication required)
  • reauthorisation (Notes: No cardholder authentication required)
  • noShow (Notes: No cardholder authentication required)
  • charge (Notes: SCA takes place)

String

Yes

FAQ

  • I was doing recurring payments before, how is my integration affected?

    In that case, you do not require to send any new parameter. All defaults are modelling the recurring flow. However, the recurring flow is not supposed to be used for instalment or unscheduled. If that is the case, you will have to setup a new agreement. If you are unsure, please contact support.

  • Will you deprecate verifyCard?

    It is not our plan, but we are looking into an agreement API, which will function in the same way as the current subscription API. We recommend you integrate to the latter instead.