Payabl.

Connect H2H Merchant account in Corefy Dashboard

Step 1 - Open connection form

Open Payabl. in the provider directory and press Connect at Payabl. Provider Overview page in the New connection section. Choose H2H Merchant account.

Step 2 - Fill in fields and select settings

• Merchant ID
• Secret Key
• API URL
• Save Instant Token
• Default Address Params
• Use MPI (optional)
• Acquirer BIN (required if Use MPI is enabled)
• Acquirer Merchant ID (required if Use MPI is enabled)
• Acquirer Country Code (optional)
• Acquirer Country Code Source (optional)
• Username / Password (optional)
• Transactions Log API URL (optional)
• Test Mode -> (enable if you are using sandbox credentials)

Choose Currency / Features; check with your Corefy account manager which are enabled for your account.

First request to Corefy API (MIN)

What it does: creates a payment-invoice; card data itself is collected and submitted separately by Corefy's checkout/SDK layer, not as part of this request. Payabl. may return a 3D Secure challenge redirect depending on the card. CVV is always required - non-CVV sales aren't supported.

Payment - MIN

POST /api/payment-invoices

{
  "data": {
    "type": "payment-invoice",
    "attributes": {
      "reference_id": "8e3dbbb0-17af-4c9a-bedb-93bdac6900a2",
      "service": "payment_card_eur_hpp",
      "currency": "EUR",
      "amount": 10
    }
  }
}

This connector also supports USD, GBP.

Payment - MAX

POST /api/payment-invoices

{
  "data": {
    "type": "payment-invoice",
    "attributes": {
      "reference_id": "6795502c-e27d-4d07-85e0-93245aab9a3f",
      "service": "payment_card_eur_hpp",
      "currency": "EUR",
      "amount": 10,
      "customer": {
        "reference_id": "cus_123",
        "name": "John Smith",
        "email": "johnsmith@gmail.com",
        "date_of_birth": "1990-01-01",
        "address": {
          "country": "FR",
          "region": "IDF",
          "city": "Paris",
          "street": "1 Main street",
          "post_code": "75000"
        },
        "metadata": {
          "nationality": "FR"
        }
      }
    }
  }
}

customer is entirely optional - anything you don't send falls back to the Constants below, or to the selected Default Address Params preset. The cardholder's first/last name sent to Payabl. always comes from the card's own embossed name, not from customer.name.

Extended request (MAX)

Why add extra fields (typical reasons): - Provide additional customer details for compliance/reconciliation - Positively influence conversion rate - Include optional fields required by your specific flow

Options

• ignore_callback -> optional, boolean - for cascading to work correctly, excludes finalizing the payment from the asynchronous callback; Corefy then relies only on an active status request (reconciliation) to finalize it.
• set_fail_without_reconciliation -> optional, boolean - if the payment's current status already falls into a "failed" group, a reconciliation check reports it as failed immediately instead of asking Payabl. for a fresh status.
• use_alpha3_country -> optional, boolean - sends country (whether from the request, the COUNTRY constant, or the Default Address preset) as a 3-character code (e.g. DEU) instead of the format you sent it in.

Constants (fallback fields)

Constants are static values that Corefy can send to the provider instead of dynamic data from your API request, when those fields are missing in the request.

Priority (predictable rule): 1. If a value is present in the request -> Corefy uses the request value 2. Else if the constant is set -> Corefy uses the constant 3. Else -> the selected Default Address Params preset's value is used (never a rejection)

If you configure all five address Constants (STREET/POST_CODE/CITY/REGION/COUNTRY), the Default Address preset's values are never actually used - this is the recommended approach if none of the four presets fits your business.

Currently available constants (constant -> Corefy API field)

• EMAIL -> customer.email
• STREET -> customer.address.street / customer.address.full_address
• POST_CODE -> customer.address.post_code
• CITY -> customer.address.city
• REGION -> customer.address.region
• COUNTRY -> customer.address.country
• NATIONALITY -> used only when customer.metadata.nationality isn't sent; always converted to a 3-character code regardless of use_alpha3_country

Refunds

Payabl. supports partial and multiple refunds against the same payment.

Recurring (save and charge a token)

This connector supports saving the card as a token during a sale (via Corefy's standard tokenize-on-sale request, enabled through Save Instant Token) and later charging that same token without sending full card data again.

Connect Provider account in Corefy Dashboard

Step 1 - Open connection form

Open Payabl. in the provider directory and press Connect at Payabl. Provider Overview page in the New connection section. Choose Provider account.

Step 2 - Fill in fields and select settings

• Merchant ID
• Secret Key
• API URL
• Test Mode -> (enable if you are using sandbox credentials)

First request to Corefy API (MIN)

What it does: creates a payment-invoice and redirects the customer to a Payabl.-hosted page to complete the payment with card, Apple Pay, or Google Pay. The exact methods/currencies available depend on what's enabled for your specific account - check with your account manager.

Payment - MIN

POST /api/payment-invoices

{
  "data": {
    "type": "payment-invoice",
    "attributes": {
      "reference_id": "8e3dbbb0-17af-4c9a-bedb-93bdac6900a2",
      "service": "applepay_eur_hpp",
      "currency": "EUR",
      "amount": 10
    }
  }
}

This connector also supports googlepay_eur_hpp and payment_card_eur_hpp, plus Apple Pay in GBP, USD, AUD, and CAD.

Payment - MAX

POST /api/payment-invoices

{
  "data": {
    "type": "payment-invoice",
    "attributes": {
      "reference_id": "6795502c-e27d-4d07-85e0-93245aab9a3f",
      "service": "applepay_eur_hpp",
      "currency": "EUR",
      "amount": 10,
      "customer": {
        "reference_id": "cus_123",
        "name": "John Smith",
        "email": "johnsmith@gmail.com"
      }
    }
  }
}

customer is entirely optional - everything is only used to prefill the hosted form, it never blocks the sale.

Extended request (MAX)

Why add extra fields (typical reasons): - Provide additional customer details for compliance/reconciliation - Positively influence conversion rate - Include optional fields required by your specific flow

No Options are configured for this flow.

Constants (fallback fields)

Configured per Apple Pay service (applepay_<ccy>_hpp) only.

Currently available constants (constant -> Corefy API field)

• WEBSITE_URL -> your website URL, sent to Payabl. for Apple Pay domain verification; falls back to your merchant profile's own website if not set

Refunds

This flow does not support refunds - use the H2H Merchant account if you need refunds.

Apple Pay / Google Pay buttons inside your own site - no redirect to a Payabl.-hosted page. Corefy creates a Web SDK session, you get a session_id and initialize Payabl.'s Web SDK with it.

Apple Pay certificates are managed by Payabl., but your domain must pass Apple Pay domain verification on Payabl.'s side before production.

Connect Provider account in Corefy Dashboard

Same Provider account connection as the hosted-page flow above - Merchant ID, Secret Key, API URL, Test Mode.

In Currency / Features enable:

• applepay_usd_invoice - Apple Pay, USD
• googlepay_usd_invoice - Google Pay, USD

First request to Corefy API (MIN)

What it does: creates a payment-invoice and a Payabl. Web SDK session; the response carries the session_id.

Payment - MIN

POST /api/payment-invoices

{
  "data": {
    "type": "payment-invoice",
    "attributes": {
      "reference_id": "8e3dbbb0-17af-4c9a-bedb-93bdac6900a2",
      "service": "applepay_usd_invoice",
      "currency": "USD",
      "amount": 5,
      "customer": {
        "metadata": {
          "ip": "93.61.19.51"
        }
      }
    }
  }
}

Also supported: googlepay_usd_invoice. Both services are USD only.

Where to read session_id

{
  "data": {
    "id": "pay_0Jk46PFmBKtFqCMTdxcXFj84",
    "type": "payment",
    "attributes": {
      "status": "process_pending",
      "flow_data": {
        "credentials": {
          "session_id": "6a6a107271416a664fedfb2015a72ba18e65b297"
        }
      }
    }
  }
}

• One session_id = one payment attempt. For a retry create a new payment-invoice.
• Payment is process_pending at this point - the session_id confirms nothing, it only unlocks the button.
• Not a secret - it is meant for the browser, and it is bound to your account, amount, currency and order.
• Unused sessions expire on Payabl.'s side.
• No session_id in the response -> session creation failed (credentials, method not enabled, missing customer data). Check the payment's resolution instead of retrying.

Payment - MAX

POST /api/payment-invoices

{
  "data": {
    "type": "payment-invoice",
    "attributes": {
      "reference_id": "6795502c-e27d-4d07-85e0-93245aab9a3f",
      "service": "applepay_usd_invoice",
      "currency": "USD",
      "amount": 5,
      "customer": {
        "reference_id": "cus_123",
        "first_name": "Fabio",
        "last_name": "Tovar",
        "email": "fabio@mintstars.com",
        "metadata": {
          "ip": "93.61.19.51"
        }
      }
    }
  }
}

first_name, last_name, email, metadata.ip -> Payabl. firstname, lastname, email, customerip.

Rendering the button

1. Create the payment-invoice, read session_id from flow_data.credentials.
2. Initialize the Payabl. Web SDK with that session_id and the methods to show:
   • [119] - Apple Pay only
   • [121] - Google Pay only
   • [119, 121] - both
3. Only the passed methods are rendered in the iframe - keep the list aligned with the service used for the payment.
4. The customer confirms in the wallet sheet; no redirect to the Payabl. hosted page.

Options

• finalize_after_minutes -> optional, number - how long a non-final payment stays pending before reconciliation finalizes it as expired (abandoned wallet sheet).

Constants (fallback fields)

Constants are static values that Corefy can send to the provider instead of dynamic data from your API request, when those fields are missing in the request.

Currently available constants (constant -> Corefy API field)

• WEBSITE_URL -> domain where the button is shown, sent as shop_url; your merchant profile's website URL wins, this is the fallback
• LANGUAGE -> 2-letter Web SDK language code; defaults to en

Refunds

Full and partial refunds for captured payments, several per payment until the original amount is used up. Beyond that Payabl. rejects it: refund failed : paymentsystem can not refund.

Testing

• Google Pay - end-to-end on the Payabl. public sandbox.
• Apple Pay - not supported on the public sandbox; needs a dedicated sandbox account and a verified domain.
• Success: any test card in the wallet. Decline: test amounts from Payabl.'s Bank Responses.

Connect Provider account in Corefy Dashboard

Uses the same Provider account connection as Payments above - one connection covers both directions, nothing extra to fill in for payouts specifically.

First request to Corefy API (MIN)

What it does: creates a payout-invoice and sends funds directly to a card.

Payout - MIN

POST /api/payout-invoices

{
  "data": {
    "type": "payout-invoice",
    "attributes": {
      "reference_id": "0dde9e79-2c64-4703-adaf-93d710633401",
      "service": "payment_card_eur",
      "currency": "EUR",
      "amount": 10,
      "fields": {
        "card_number": "4111111111111111"
      }
    }
  }
}

Payout - MAX

POST /api/payout-invoices

{
  "data": {
    "type": "payout-invoice",
    "attributes": {
      "reference_id": "3c6d2f8e-8a2a-4e7a-9b1a-2f6a7b9c0d1e",
      "service": "payment_card_eur",
      "currency": "EUR",
      "amount": 10,
      "customer": {
        "reference_id": "cus_123",
        "name": "John Smith"
      },
      "fields": {
        "card_number": "4111111111111111"
      }
    }
  }
}

customer is entirely optional - name, when sent, is forwarded as the receiver's name.

Extended request (MAX)

Why add extra fields (typical reasons): - Provide additional customer details for compliance/reconciliation - Positively influence conversion rate - Include optional fields required by your specific flow

No Options or Constants are configured for this flow.