Integrate using SERVER-TO-SERVER

Connect directly with the gateway server to process payments

From a PCI DSS-compliant environment, you can directly integrate with the CardCorp gateway server using the SERVER-TO-SERVER API. See How do I know if I'm PCI compliant.

With this integration, you can accept synchronous debit payments or use preauthorisation and capture. You can perform 3DS validation with your own MPI or the CardCorp gateway MPI.


PCI DSS 4.x

Your website payment pages must comply with PCI DSS v4.x, which is designed to stop attackers from obtaining cardholder data when you are processing it in your e-commerce system.

For full details of PCI DSS 4.x, see the gateway documentation and the PCI 4.0.x documentation.


Before you begin

The gateway has test and live environments with different base URLs.

TEST - https://eu-test.oppwa.com/v1/
LIVE - https://eu-prod.oppwa.com/v1/

You can make API requests to the endpoints of these environments by adding the resource paths, such as checkouts or checkouts/{id}/paymentsto the end of the base URL.

Get your CardCorp gateway authentication credentials from our technical support team.

You will have one set of credentials for the test environment and another for the live environment.

Each set of API credentials has one entity ID (also called the channelID) and one API authorisation token.

📘

API credentials

Remember to use the appropriate API endpoint and credentials for each environment, because this is a common cause of errors!


Test cards

When you are testing your integration, use the gateway test cards.

See Gateway test documentation.

Do not use live card data in the test environment.


Payment flows for SERVER-TO-SERVER integrations

The following diagram shows the payment flows with gateway 3DS, but if you are using your own 3DS, you can skip the 3DS redirect here and add the 3DS data to your payment request directly.

%%title: Server-to-server payment flows
flowchart TB
    SinglePayment["Single payment"]
    SubmitPaymentSP["Submit
    payment"]
    Handle3dsSP["Handle 3DS
    redirect"]
    GetResponseSP["Get payment
    response"]
    
    OneClickCheckout["One-click checkout"]
    SubmitPaymentOC["Submit
    payment"]
    Handle3dsOC["Handle 3DS
    redirect"]
    GetResponseOC1["Get payment
    response"]
    CreateCheckoutOC["Use registration
    ID to display
    one-click
    checkout"]
    GetResponseOC2["Get payment
    response"]
        
    RecurringISM["Instalment,
    subscription, and
    metered"]
    SubmitPaymentISM["Submit
    payment"]
    Handle3dsISM["Handle 3DS
    redirect"]
    GetResponseISM1["Get payment
    response"]
    GetRepeatedISM["Submit repeated
    payment"]
    GetResponseISM2["Get repeated
    payment
    response"]

		SinglePayment --> SubmitPaymentSP
		SubmitPaymentSP --> Handle3dsSP
		Handle3dsSP -->  GetResponseSP
    
		OneClickCheckout --> SubmitPaymentOC
		SubmitPaymentOC --> Handle3dsOC
		Handle3dsOC -->  GetResponseOC1
		GetResponseOC1 --> CreateCheckoutOC
		CreateCheckoutOC --> GetResponseOC2

		RecurringISM --> SubmitPaymentISM
		SubmitPaymentISM --> Handle3dsISM
		Handle3dsISM -->  GetResponseISM1
		GetResponseISM1 --> GetRepeatedISM
		GetRepeatedISM --> GetResponseISM2
    
classDef yellow fill:Ivory,stroke:#333,stroke-width:0.5px
classDef green fill:HoneyDew,stroke:#333,stroke-width:0.5px
classDef orange fill:NavajoWhite,stroke:#333,stroke-width:0.5px
classDef lilac fill:GhostWhite,stroke:#333,stroke-width:0.5px
classDef pink fill:Pink,stroke:#333,stroke-width:0.5px
classDef blue fill:#cfefff,stroke:#333,stroke-width:0.5px
classDef white fill:white,stroke:#333,stroke-width:0.5px
linkStyle default stroke:#333,stroke-width:0.5px,color:#333

class SinglePayment white
class SubmitPaymentSP lilac
class Handle3dsSP lilac
class GetResponseSP lilac

class OneClickCheckout white
class SubmitPaymentOC lilac
class Handle3dsOC lilac
class GetResponseOC1 lilac
class CreateCheckoutOC lilac
class GetResponseOC2 lilac

class RecurringISM white
class SubmitPaymentISM lilac
class Handle3dsISM lilac
class GetResponseISM1 lilac
class GetRepeatedISM lilac
class GetResponseISM2 lilac


Collect a payment

To create a payment request using the gateway system for 3DS verification, follow this payment flow.

  1. Create a payment request.
    1. Include attributes to request 3DS verification as part of the payment request.
    2. Include your shopperResultUrl where the gateway will redirect your customer.
  2. Handle the 3DS verification.
    1. Get the redirect object from the payment response.
    2. Open a hidden iframe for the 3DS verification.
    3. Handle pre-condition elements.
    4. Redirect the customer to the verification site.
  3. Get the result of the payment and display it when the customer is redirected to the shopperResultUrl

You can also create a request for a payment that is exempt from 3DS verification or create a payment request using your own MPI.


Collect a repeated payment

After collecting an initial payment for an instalment, subscription, or metered order, you can collect a repeated payment with the following flow.

  1. Create a payment request.
    1. From the initial payment response, add the CardholderInitiatedTransactionID.

If you are creating a custom checkout, add the card's registrationId.


Manage payments

After a payment is approved, you can manage it using the back-office API operations.

See Backoffice API operations.


Payment flows

See the documentation of each payment and verification flow on the following pages.


Testing the payment flows

The payment flow pages above provide example requests and parameters in cURL format. You can also use the comprehensive gateway playground with code samples in all major programming languages.

You can find the gateway playground at Integration Guide, and you can obtain example data for each request at Gateway playground SERVER-TO-SERVER data.

Questions? - Sign up on our website and talk to our payment experts to learn more about integrating using the SERVER-TO-SERVER API.