One-time or recurring payment

This chapter will describe the flow of performing either a one-time or recurring payment.

Step 1: Request a payment

The first step is that the merchant sends a POST request to Globadyme.

Expected is a JSON body containing the transaction data and the merchant password, provided by Globadyme. 

Url: https://sandbox.globadyme.com/api/globadymeGateway/transaction/requestPayment

Request example for one-time payment:

The following transaction fields are mandatory for all payments:

• merchantId

• amount

• currency

• country

• description (provided by the merchant. NB: this description will show up on bank statements and such)

• accountHolderName (provided by merchant)

The password field is also mandatory and is provided by Globadyme as your API Password.

The following fields are mandatory for Klarna payments:

• klarnaSpec: In order to be able to process Klarna payments, this field and its sub elements must be filled.

  • billingAddress: containing the following mandatory sub elements:

    • attention: the attention string, for example the department of the addressee

    • email: Customer e-mailaddress

    • city

    • familyName

    • givenName

    • phoneNumber

    • postalCode

    • region

    • streetAddress1

    • streetAddress2 (if applicable)

    • title

  • orderItems: A list of the items being ordered. Note that the sum of the totalAmounts must add up to the total transaction amount. If not, the payment request wil be rejected. Has the following mandatory sub elements:

    • name

    • quantity

    • totalAmount: The total amount in cents

    • unitPrice: unit price in cents

Example of a Klarna payment request:

The following fields are mandatory for recurring payments:

• transactionRecurrenceType. This will default to ONETIME if not present. For recurring payments, this field needs to be present and filled with FIRST. This will then be the first in a series of recurring payments, also serving as the mandate for future payments. Scheduling and execution of subsequent recurrences are handled by Globadyme according to parameters set in the next field.

• recurrence. Its sub elements are (all mandatory):

  • recurrenceStatus (must be ACTIVE)

  • startDate: the date at which the first recurrence is to take place. This is NOT the date where the initial transaction will take place, but when the first recurrence will take place.

  • recurrenceAmount: The amount to be paid on each recurrence. This amount does not have to be the same as the initial transaction amount.

  • recurrenceFrequency: The frequency at which recurrences should be executed. The frequency will come into play after the startDate. For example, when the startDate is 2023-08-01 and the recurrenceFrequence==MONTHLY, the first recurrence will be executed on 2023-08-01, the second on 2023-09-01, etc. Possible values:

    • DAILY

    • WEEKLY

    • MONTHLY

    • QUARTERLY

    • YEARLY

Example of recurring payment request:

The following fields are mandatory for SEPA payments:

• sepaSpec: Container for the SEPA properties

  • emailAddress: the buyer's e-mailaddress

  • postalAddress: the buyer's postal address

  • iban: The buyer's IBAN 

Example of a SEPA payment request:

Step 2: Receive a response

After sending your request, you will receive a response containing a redirect url. 

The response also contains a requestId which is unique for this transaction request. We'll see this ID again in the Callback chapter.

Response example for any (one-time or recurring) transaction:

Step 3a: Redirect your customer to the redirectUrl provided in the response.

There, the customer will choose their preferred payment method and perform the actual payment.

When customer payment flow is completed, aborted or failed, the customer will be redirected to the relevant merchant redirect URL you have specified in your Globadyme Merchant dashboard.

Step 3b: Initiate a payment through API

Alternatively, it is possible to use your own payment page and send the information to the Globadyme API.

Url: https://sandbox.globadyme.com/api/globadymeGateway/transaction/initiatePayment

Example:

Mandatory elements:

• encryptedTransaction: The encrypted transaction as received in the return url in step 2.

• requestId: The request ID as received in step 2.

• paymentMethod: The payment method as chosen by the consumer. Case insensitive. Valid payment methods:

  • IDEAL

  • PAYPAL

  • KLARNA

  • CREDITCARD

  • EPS

  • GIROPAY

  • SOFORT

  • PAYCONIQ

  • SEPA

  • BANCONTACT

Step 4: Receive a callback from Globadyme. 

You will receive a callback from Globadyme.

This will be POSTed to the (https) endpoint you specified in your Globadyme Merchant dashboard.

The callback will contain status information about your transaction.

It will also contain a requestId, which will be the same as the requestId you received as a response to the requestPayment call. You can use this requestId to match the callback to a request you sent. RequestId will never show up on any bank statements.

The message contains a signature header. This header is a SHA-512 hash of the JSON body and the callback secret (which is provided by Globadyme). You should use this to verify the authenticity of the message. 

Example in Java:signatureHash = bytesToHex(digest.digest((notification + notifySecret).getBytes()));

Example of a callback:

Step 5: Optional - Request payment status

Besides processing notifications described in the previous chapter, there is the option of requesting a transaction's status based on the requestId.

Url: https://sandbox.globadyme.com/globadymeGateway/transaction/getPaymentByRequestId

The endpoint expects a GET request with an application/json Content-Type.

Example of a request:

Mandatory fields:

• password: The API password as provided by Globadyme

• merchantId: The merchant UUID as provided by Globadyme

• requestId: The requestId as received in response to the concerning /requestPayment call

Example of a response:

Note: The response object contains a ‘transactions’ list because it is possible that one request has produced more than one transaction. For example: an end user has initiated a payment using payment method A and decided not to complete the payment. After pressing ‘back’, the end user initiated a new payment using payment method B.  In this case, there can be more than one transaction with the same requestId:

In this case one can check if there is any transaction with a “PROCESSED” status to confirm that a successful payment has been made.

Changing recurrences

After creating a recurrence, it may be desirable to change properties of this recurrence.
In order to do so, one can send a changeRecurrence request.

Note: this request requires you send a bearer token in the Authorization header.
Note2: the existing recurrence will end effective immediately.

Url: https://sandbox,globadyme.com/api/globadymeGateway/recurrence/changeRecurring

Example:

Mandatory fields:

• recurrenceFrequency: The new frequency at which executions should take place. Note: This frequency will start after the startDate parameter. Possible values:

  • YEARLY

  • QUARTERLY

  • MONTHLY

  • WEEKLY

  • DAILY

• recurrenceAmount: The amount to be transferred at each execution.

• startDate: The date at which the new recurrence should take effect.

• transactionId: The ID of the original transaction on which the original authorization was given.

• description: The description for the new recurrence.

• id: The ID of the recurrence to be replaced by the new recurrence.

Example response:

The response will contain the id of the new recurrence.

Stopping recurrences

This endpoints facilitates the stopping of a recurrence. Note: this request requires you send a bearer token in the Authorization header.

Url: https://sandbox.globadyme.com/api/globadymeGateway/recurrence/stopRecurring

Example:

Mandatory fields:

• id: The ID of the recurrence to be stopped.

Example response: