This integration follows ACI's ConnectIn specification. Payment Initiation Messages are accepted exactly as ConnectIn sends them: application/x-www-form-urlencoded with dot notation for nested fields and bracket notation for custom parameters. Parameters we do not recognise are ignored rather than rejected.

Endpoints

Method URL Purpose
POST https://process.coriunder.cloud/v1/payments Payment initiation - PA, DB and CD
POST https://process.coriunder.cloud/v1/payments/{UUID} Referenced operation against a previous payment - RF, RV and CP

1 {UUID} is the value you sent as customParameters[UUID] on the original payment.

Authentication

Either an authentication block or a Bearer token. As per the ConnectIn specification the two must not be used together - send one or the other. Both resolve to the same merchant.

Field Description Required
Authorization HTTP header. Bearer {CompanyNum}.{token} where token is the value we issue you Either this
authentication.entityId Your company number - ####### or this block
authentication.password Your personal hash key With entityId
authentication.userId Your company number - ####### With entityId

The Bearer token is derived as base64(sha256(CompanyNum + PersonalHashKey)), prefixed with the company number and a dot. It is stable, so it can be configured once. Rotating the hash key changes the token.

Token example

Bearer token
var raw = CompanyNum + PersonalHashKey;
var digest = CryptoJS.SHA256(raw).toString(CryptoJS.enc.Base64);
var token = CompanyNum + "." + digest;

// Authorization: Bearer 7022221.qQnAIBhwpD1Pn6SG9iNrg8sGk+0pM4x38+B/HzJsmQM=

Request Fields

Field Description MaxLength Required
customParameters[UUID] Your identifier for the payment. Returned as id and used to reference the payment later 64 Yes
customParameters[ShortId] Your secondary identifier. Stored for reconciliation 64 Optional
paymentType PA, DB, CD, RF, RV or CP. Defaults to DB when omitted 2 Yes
amount Payment amount, for example 92.00 12 Yes
currency Three letter ISO code, for example EUR 3 Yes
paymentBrand VISA, MASTER and so on. Echoed back on the response 50 Optional
merchantTransactionId The merchant's own reference 100 Optional
descriptor Payment description 200 Optional
card.number The card holder card number 20 Yes 1
card.expiryMonth Two digit month, for example 03 2 Yes 1
card.expiryYear Four digit year, for example 2029 4 Yes 1
card.cvv CVC verification number 5 Optional
card.holder Card holder name. Falls back to customer.givenName plus customer.surname 100 Yes 1
customer.email Card holder email address 100 See 2
customer.mobile Card holder phone number. customer.phone is accepted as an alternative 20 See 2
customer.birthDate Date of birth, YYYY-MM-DD 10 See 2
customer.ip The shopper's IP address. Used for risk scoring 45 Recommended
customer.givenName Card holder first name 50 Optional
customer.surname Card holder last name 50 Optional
billing.street1 Billing address line 1. billing.street2 is also accepted 100 Optional
billing.city Billing city 50 Optional
billing.postcode Billing postal code 20 Optional
billing.state Billing state 50 Optional
billing.country Billing country, two letter ISO code 2 Optional
notificationUrl Your asyncresponse URL. We call it with the final status once an asynchronous payment settles 2000 Yes 3
shopperResultUrl Where the shopper is sent once the payment completes. Used exactly as supplied 2000 Yes 3

1 Card fields are required for PA, DB and CD. Referenced operations - RF, RV and CP - take the card from the original payment and must not resend it.
2 Optional by default, but some merchant profiles make phone, email or date of birth mandatory. When a required field is missing the payment is rejected before it is routed, with result code 200.300.404.
3 Required for any payment that may need 3D Secure. Without them an asynchronous payment cannot be completed.

Request example

Request
POST https://process.coriunder.cloud/v1/payments
Authorization: Bearer 7022221.qQnAIBhwpD1Pn...
Content-Type: application/x-www-form-urlencoded

amount=92.00&
currency=EUR&
paymentType=DB&
paymentBrand=VISA&
customParameters[UUID]=a785cabfa77d404e9f34ec9f55be56ac&
customParameters[ShortId]=a785cabf&
merchantTransactionId=order-10231&
descriptor=Coffee+subscription&
card.number=4111111111111111&
card.expiryMonth=03&
card.expiryYear=2029&
card.cvv=123&
card.holder=Test+Holder&
customer.email=test%40example.com&
customer.mobile=%2B15492001234&
customer.ip=203.0.113.24&
billing.street1=Barkat+12&
billing.city=Holon&
billing.postcode=5544888&
billing.country=IL&
notificationUrl=https%3A%2F%2Ftest.ppipe.net%2Fconnectors%2Fasyncresponse%3F...&
shopperResultUrl=https%3A%2F%2Fshop.example.com%2Fdone

Payment types

Type Meaning Endpoint
DBDebit - immediate sale/v1/payments
PAPre-authorisation 1/v1/payments
CDCredit/v1/payments
CPCapture of a PA/v1/payments/{UUID}
RVReversal - void/v1/payments/{UUID}
RFRefund/v1/payments/{UUID}

1 PA has to be enabled on the merchant profile. If the referenced UUID cannot be found we answer 700.100.100.

Response Fields

Field Description
id The UUID you supplied in customParameters[UUID]
paymentType The payment type processed
paymentBrand Echoed from the request when supplied
amount / currency The amount processed, normalised to two decimals
merchantTransactionId Echoed from the request when supplied
descriptor Echoed from the request when supplied
card.bin First six digits of the card
card.last4Digits Last four digits of the card. The full number is never returned
card.holder, card.expiryMonth, card.expiryYear Card holder details as processed
result.code The ACI result code. See the table below
resultDetails.AcquirerResponse Our internal reply code, kept for reconciliation and support
resultDetails.ExtendedDescription Human readable description of the reply
redirect.url Present only for asynchronous payments. Absolute URL to send the shopper to
redirect.method Always GET
timestamp yyyy-MM-dd HH:mm:ss ZZZZ

Result codes

Code Meaning
000.000.000Approved
000.200.000Pending. A redirect block is included and the final status follows on the notificationUrl
000.400.110Held for manual risk review
100.100.101Invalid card number
100.550.300No amount or amount too low
200.300.404A required field is missing or malformed
700.100.100The referenced UUID does not exist
700.400.200Capture exceeds the authorised amount
800.100.100Declined by the issuer or provider
800.300.101Blocked by a risk or blacklist rule
800.900.300Authentication failed, or the merchant is not configured for this operation
900.100.100No response from the processing host. The outcome is unknown - see Idempotency

Response example

Approved
{
  "id": "a785cabfa77d404e9f34ec9f55be56ac",
  "paymentType": "DB",
  "paymentBrand": "VISA",
  "descriptor": "Coffee subscription",
  "amount": "92.00",
  "currency": "EUR",
  "merchantTransactionId": "order-10231",
  "card": {
    "bin": "411111",
    "last4Digits": "1111",
    "holder": "Test Holder",
    "expiryMonth": "03",
    "expiryYear": "2029"
  },
  "result": { "code": "000.000.000" },
  "resultDetails": {
    "AcquirerResponse": "000",
    "ExtendedDescription": "SUCCESS"
  },
  "timestamp": "2026-08-25 10:53:25 +0000"
}

Pending example

3D Secure required
{
  "id": "a785cabfa77d404e9f34ec9f55be56ac",
  "paymentType": "DB",
  "amount": "92.00",
  "currency": "EUR",
  "result": { "code": "000.200.000" },
  "resultDetails": {
    "AcquirerResponse": "553",
    "ExtendedDescription": "3D Secure Redirection is needed"
  },
  "redirect": {
    "url": "https://process.coriunder.cloud/member/remoteCharge_Back.asp?TransID=18081&CompanyNum=7022221",
    "method": "GET"
  },
  "timestamp": "2026-08-25 10:53:25 +0000"
}

Asynchronous payments

When a payment needs 3D Secure we answer 000.200.000 with a redirect block. From there:

  1. Send the shopper to redirect.url. The URL is always absolute and is used with GET.
  2. The shopper authenticates and we finalise the payment.
  3. We call your notificationUrl with the final status and a signature, as described below.
  4. We then redirect the shopper to the shopperResultUrl from the original request, unchanged.

The status notification is always sent before the shopper redirect, and it is sent exactly once per payment even if the shopper returns at the same moment the payment settles.

Status notification

Notification and signature
GET {notificationUrl}
  &status=000.000.000
  &resultDetails.ExtendedDescription=SUCCESS
  &signature={hex}

// signature is HMAC-SHA256 over every query
// parameter, sorted by name and joined with "|",
// keyed with your personal hash key, hex encoded.

asyncsource=UCONNECT|data=abc|method=CC|
ndcid=1|resultDetails.ExtendedDescription=SUCCESS|
status=000.000.000|type=notification|uuid=...

Idempotency

A repeated Payment Initiation Message carrying a UUID we have already answered returns the stored answer, including the original redirect, rather than charging the card a second time. Retries are therefore safe.

The one case that needs attention is 900.100.100. It means we did not get a usable reply from the processing host and the outcome is genuinely unknown, so we neither approve nor decline. Retrying returns the same answer rather than risking a double charge. Contact support with the UUID to have the payment reconciled.

3D Secure flow

Learn how 3DS transactions are processed.
Wrong signature

What to check when authentication fails.
Server to Server overview

The standard server to server integration.