Card issuing

PSD2 (Directive (EU) 2015/2366) lists "issuing of payment instruments" as a payment service in point 5 of Annex I. Article 4(45) defines it as "a payment service by a payment service provider contracting to provide a payer with a payment instrument to initiate and process the payer's payment transactions". The Interchange Fee Regulation (EU) 2015/751 defines a card-based payment instrument to include a card, a mobile phone or any other device with the right payment application (Article 2(20)), so a virtual card that lives in an app or a phone wallet is a payment instrument in the same way as a plastic one.

Each card payment involves several parties. The issuer has the contract with the cardholder and authorizes transactions under the rules of a card scheme such as Visa or Mastercard. The acquirer serves the merchant. A processor often runs authorization, card records and transaction data for the issuer. A company that wants to put a card in its customers' hands, such as a lender, does not have to become an issuer. It can work with a licensed issuer and build the customer side of the product around that partner.

The IFR separates debit card transactions from credit card transactions. In a credit card transaction the amount is debited in full or in part at a pre-agreed date "in line with a prearranged credit facility, with or without interest" (Article 2(5)). This is the case that matters to a lender: the card becomes a way for the customer to draw on a credit limit the lender grants. Interchange on consumer credit card transactions is capped at 0.3% of the transaction value (Article 4), and on debit card transactions at 0.2% (Article 3).

The issuer's processor holds the card, the authorizations and the card transactions. The lender's system holds the customer, the credit agreement and the limit. The app reads from both, so every amount and status it shows has to agree with the other two systems.

Card data needs its own security model. Article 70 of PSD2 requires the issuing provider to keep personalized security credentials, such as the PIN, out of reach of anyone but the user. The RTS on strong customer authentication (Delegated Regulation 2018/389, Article 22) require such credentials to be masked when displayed and never stored in plain text. This covers the PIN. The card number and CVV are a different case. The EBA has said that card details printed on the card cannot be a valid possession element for strong customer authentication (Q&A 2018_4235), so they are not an authentication factor, and how the app shows them follows the issuer's and the card scheme's security rules, such as the card industry's data security standard. Good practice is to decrypt them on the device, only after a PIN or biometric check, hide them again after a set time and when the customer leaves the screen, and keep those screens out of analytics and session recordings.

Blocking has to work at any hour. Under Article 70(1)(c) and (e) the issuer must let the user report a lost or stolen card at all times and must stop all use of the card once it has been reported. Article 68 lets the provider block a payment instrument with a credit line when the risk that the payer cannot pay has increased significantly, and requires it to tell the payer. In the app, block, unblock and cancel should take effect at once with a visible status, and a reissued card should lead the customer straight to setting a new PIN.

Limits live in two places. The credit limit comes from the credit agreement. Daily and monthly spending limits are card settings that the payer and the provider may agree under Article 68(1). Every screen that shows the credit limit, from signing the agreement to the card tab, has to read the same value.

Transactions arrive as events. Authorizations, bookings, fees, repayments and due-date reminders come from the processor asynchronously. The backend has to consume them reliably, map each type to a status the customer understands, such as pending or booked, and decide which of them send a push notification. Statements, the repayment schedule and the card's APR in the calculator have to match the same data.

PSD2 governs the issuer, which needs an authorization as a payment service provider. Under Article 18(4) a payment institution may grant credit linked to payment services only if the credit is ancillary to a payment transaction and is repaid within 12 months at most. Article 74 limits the payer's loss from a lost or stolen card to EUR 50, except in cases of fraud or gross negligence, and to nothing once the card has been reported. In November 2025 the European Parliament and the Council reached a provisional agreement on PSD3 and a Payment Services Regulation (PSR) that will replace PSD2 and move most of its rules into a directly applicable regulation. As of October 2026 the new rules do not yet apply: they start after formal adoption, publication in the Official Journal and a transition period, so PSD2 and the RTS remain the rules to build against today.

The credit line falls under consumer credit law. In Poland, Article 36d of the Consumer Credit Act excludes from the cap on non-interest costs in Article 36a an agreement for a credit card (IFR Art. 2(34)), but only when the lender "is also the issuer of the credit card". A lender that offers a card through an issuing partner should ask its lawyer whether the cap applies to its card product, and its pricing logic should be able to handle the stricter answer.

In Aasa24, the lending app we have built for Aasa Polska since May 2023, the second stage (July 2024 to January 2025) added a Visa card with a credit limit. An external, licensed issuer in the Visa network issues the card and Aasa Polska provides the credit limit. We built the app, the backend and the integration with the issuer's systems. Card events from the external system reach the backend through a Kafka connection over a VPN tunnel.

In the app the customer applies for the card with an online identity check, sets the PIN on the phone and can add the card to Google Pay. The customer can block, unblock and cancel the card and set daily and monthly limits, and each change is confirmed with the PIN. The card number and CVV are decrypted on the device in our own native module and are hidden again after 60 seconds. Card features were switched on remotely with feature flags, for Android and a test group first. In 2025 and 2026 we also made the credit limit show the same amount on the agreement signing screen, the agreement details and the monthly limits view.