myTU

Connect Provider account in Corefy Dashboard

Step 1 - Open connection form

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

Step 2 - Fill in fields and select settings

• Client IBAN
• Auth Private Key (upload PEM file)
• Signature Private Key (upload PEM file)
• PSP Public Key (upload PEM file)
• CPK (optional — only if myTU issued you several key pairs)
• API URL (optional — override the default provider URL)
• Test Mode -> (enable if you are using sandbox credentials)

Choose Currency and Features. You can set these parameters according to available currencies and features for your myTU account, but it is necessary to check details of the connection with your Corefy account manager.

First request to Corefy API

What it does: creates a payment-invoice. myTU's Sale operation has two request shapes, not a MIN/MAX pair — which one applies depends on whether the payer already has a mandate.

Payment

What it does: first collection for a payer — myTU has no mandate for them yet, so one is created as part of this request. This is the minimum required data for this flow.

POST /api/payment-invoices

{
  "data": {
    "type": "payment-invoices",
    "attributes": {
      "service": "sepadirectdebit_eur_invoice",
      "currency": "EUR",
      "amount": 10,
      "test_mode": true,
      "reference_id": "ORDER-1001",
      "service_fields": {
        "iban": "ES9121000418450200051332",
        "account_holder_name": "Test Debtor",
        "mandate_signed_at": "2026-07-29",
        "mandate_expire_at": "2028-07-30"
      }
    }
  }
}

{
  "data": {
    "id": "cpi_7XqR2mKpL9wZaB4C",
    "attributes": {
      "status": "process_pending",
      "flow_data": {
        "requisites": {
          "mandate_id": "9KRT4LX8B2QM",
          "charge_date": "2026-08-04",
          "mandate_seq_tp": "FRST",
          "vop_code": "NOAP"
        }
      }
    }
  }
}

Repeat payment

What it does: a later collection for a payer who already has a mandate — send its mandate_id (returned in flow_data.requisites of the first payment's response, as shown above) instead of mandate_signed_at/mandate_expire_at, and no new mandate is created. This example also shows charge_date, an optional field (in either request shape) to pick a specific collection day instead of the earliest possible one.

POST /api/payment-invoices

{
  "data": {
    "type": "payment-invoices",
    "attributes": {
      "service": "sepadirectdebit_eur_invoice",
      "currency": "EUR",
      "amount": 10,
      "test_mode": true,
      "reference_id": "ORDER-1002",
      "service_fields": {
        "iban": "ES9121000418450200051332",
        "account_holder_name": "Test Debtor",
        "mandate_id": "9KRT4LX8B2QM",
        "charge_date": "2026-08-13"
      }
    }
  }
}

mandate_seq_tp (optional, service_fields) — which collection in the mandate's series this is: FRST (first), RCUR (repeat), FNAL (last one — no further collections will be made against this mandate), or OOFF (one-off, not part of a recurring series at all). If not sent, it's worked out automatically: FRST when no mandate_id is given, RCUR when one is. Set it explicitly to FNAL for a series' last collection or OOFF for a standalone one-off collection.

charge_date (optional, service_fields) — the day the money is taken, YYYY-MM-DD. If not sent, the earliest possible day is used: D+1 if the payment is submitted before 11:15 Europe/Vilnius, otherwise D+2; capped at D+14 at the latest. Weekends and TARGET2-style holidays (New Year's Day, Labour Day, Good Friday, Easter Monday, Christmas Day, Boxing Day) are skipped in either direction. A charge_date outside this window, or falling on a non-working day, is rejected before the request reaches myTU.

Extended request

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 (e.g. charge_date above)

Options

Options are configured on the Corefy side and affect how Corefy builds provider requests or processes responses.

Currently available options (3)

• mandate_vop_policy - controls which Verification of Payee result is accepted when a new mandate is created
• refund_vop_policy - the same check, applied when confirming an outgoing refund transfer
• refund_transfer_method - how a refund is sent back to the payer