It is a value received in response to the request GET /v1/api/limits/{ppan} to get limits assigned to card. The data received in response must be used in case of Change limits data by card or Get used limits by card. Key value depends on the limit specifics, it may not be always PPAN.

DAPI does not cover such restrictions explicitly, but you can manage this by setting the appropriate limit to 0.

Yes, DECTA can authorize both per-transaction and cumulative limits.

Yes, there is an option to configure single, daily, and monthly card limits.

There are two ways of limit application: 1) Issuer side (through NIF). 2) DECTA processing side. In the latter, DECTA offers two levels: * **Card product level (group limits):** apply to all cards within the same product. * **Individual limits:** If the Issuer has "no restrictions" access rights, they can set individual limits above the group limit; otherwise, they are restricted by the group limit. Individual limits always override group limits when set.

It is up to Issuer. Expiry date is the last day of the specific month.

Issuer. Renewal function for the plastic cards is available 2 month prior expiry date.

Should use request PATCH /v1/api/cards/{ppan}/state by indicating 6 last digits of the card.

Issuer must use POST /v2/api/cards, endpoint POST v1/api/cards/order is for White Label Issuing customers.

Yes, DECTA provides letter masked PAN, for example 123456ABCDEF5678.

Use request GET /v1/api/cards/{ppan} to get all card related information.

If balances are held on Issuer's side, then POST Transactions endpoint should not be used. If balances are held on DECTA side then yes, this endpoint should be used to update balances.

No, it is up to Issuer (no specific requirements).

The card product can be configured with different card condition sets or account condition sets, for example, to apply different card and/or account fees for the same card product. In that case possible values for **card.condSet** or **accountCondSet** fields will be provided by DECTA together with card product specification. Usually card product has one card condition set and one account condition set as default and then field **card.condSet** or **accountCondSet** must stay empty.

Legacy parameter, should be ignored.

This should be agreed with perso-bureau and during card create request you will be able to choose proper delivery method.

While creating Create Card request, in object **businessClient**, add company name in field **nameOnCard**.

Issuer should build their own card lifecycle management according to their business logic. DECTA provides endpoints to receive card data and perform the necessary card management at the request of the issuer.

Values of shipment methods are agreed with perso-bureau. Shipment method value should be indicated in Create Card request in **deliveryAddress** object. Tracking availability depends on chosen shipment methods. If tracking option is available it must be agreed with perso-bureau on the way it is delivered to Issuer directly in secure way.

Issuer should not generate new Request ID, you should use the same Request ID for the second attempt. More details: https://hub.decta.com/docs/dapi/Issuing-API/Get-Started#dapi-idempotency

DECTA have 3 global Card statuses: * 0- active (for everything), * 1- soft block (for example not active card or blocked by holder, card in this status can be resolved into active), * 2 - hard block (status which blocks card permanently without restoring back). Both statuses - 1 and 2, will not give opportunity to make online card authorizations (in case of offline authorizations seller will not check card status). Settlement messages do not depend on card status. For example, if you make successful card authorization and after that you block or close the card, settlement messages will be processed anyway. Offline refund will be processed as settlement messages. Online refunds will be approved on RTPS side if card active (0) or in soft block (1).

Once the issuer initiates card account closure via API, all active cards are updated to closed (2) status. More about account closure workflow - https://hub.decta.com/docs/dapi/Issuing-API/Accounts#change-a-card-account-status

All card statuses allow offline refunds. Online refunds will be approved on RTPS side if card active (0) or in soft block (1).

You can use the PATCH request for user-defined fields to update **userDefinedField7**, which is a free custom use field designed to store specific information or conditions associated with a card.

In a response to card renew request, Issuer will receive a response including following fields: **"ppan"**: "123456ABCDEF1234" (new card number)
**"expiry"**: "2025-01-31" (new expiry date)
**"message"**: "Card marked for renewal" After renewal request, card will be embossed in the next embossing cycle. Issuer can check card status through DAPI request GET cards {PPAN}. If a request for card status is sent before embossing, Issuer will receive a response 400 Bad request message: **"Card is not embossed yet"**.

DECTA does not have auto-renewal function. Each card is renewed manually though DAPI request. Issuers can build auto-renewal logic / trigger on their side for plastic cards to send the DAPI request two month prior the expiry date. However, it must be taken into account that cardholder data may change, especially delivery address. Careful business logic must be created for such automatization.

Documentation: https://hub.decta.com/docs/dapi/Issuing-API/Notifications-and-Subscriptions

Push notification is a webhook which is delivered to issuer’s designated URLs in JSON format. In order to convert webhooks into push notifications to be sent to cardholder’s mobile devices the issuer should implement web services in its infrastructure.

Notifications can be delivered to the cardholder via SMS or to issuer's push endpoint.

No.

If your designated endpoint is unavailable or returns an error, DECTA will continue to resend the webhook/push notification every 20 seconds for 24 hours.

Basically, there are 2 options: 1. **Printed PIN version:** delivered to the issuer or directly to the cardholder as agreed with the perso-bureau in compliance with PCI DSS. 2. **Electronic PIN version:** * Via SMS: Using GET /v1/api/cards/{ppan}/pin. * Via Mobile App/Web UI (with DAPI agreement): Using GET /v2/api/cards/{ppan}/card-data7. * Via Third-party provider (if BIN owner permits): Using GET /v2/api/cards/{ppan}/card-data6.

Yes, this is a separately licensed functionality called **"PIN Assign"**. The Issuer implements endpoint /v1/api/cards/{ppan}/assign-pin to allow the cardholder to change the PIN. After the update, the cardholder must confirm it at an ATM.

No, it is up to the Issuer; there are no specific requirements from DECTA.