> ## Documentation Index
> Fetch the complete documentation index at: https://www.marqeta.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# 2022 Release Notes
> Release notes are a convenient, central location to learn about the new features, improvements, and documentation changes in each of Marqeta's products.
Marqeta Dashboard release 3.120
Changed functionality
##### Updated error message
User profile management dashboard: When an admin user adds a new user with an email domain different than the admin user’s domain, the error message now indicates the specific issue.
##### All card products now available when manually creating a cardholder or user
Card products dashboard: You can now choose from all of your card products when manually creating a cardholder or user. The card products list has been paginated, allowing you to look through multiple pages for your desired card product selection.
Marqeta Dashboard release 3.119
New features
##### Easier access to the Transaction details page
You now have three different ways to access the Transaction details page of the Marqeta Dashboard from the left-side navigation panel of the application:
* Users → Transactions
* Users → Cards → \[select a card] → Transactions → \[select a transaction]
* Businesses → Transactions → \[select a transaction]
##### Updated interface text for the 3D Secure suite
The messaging in the 3D Secure (3DS) section of the Marqeta Dashboard has been refined to reflect the latest enhancements to Marqeta’s 3DS product offering.
##### New filter type available in the transactions table
You can now filter for transactions of type `authorization.atm.withdrawal` in the transactions table by making the appropriate selection in the **Type** filter of the Marqeta Dashboard.
Notable documentation changes
New Marqeta in Europe guides
There are two new [Marqeta in Europe](/developer-guides/marqeta-in-europe-landing-page/) guides.
* To learn about authenticating online transactions with additional verification measures relevant to your card program in Europe, see [3D Secure](/developer-guides/mq-eu-3ds/).
* To learn about card tokenization and digital wallets in Europe, see [Tokenization](/developer-guides/mq-eu-tokenization/).
New Resend credit event notification endpoint reference
You can resend credit event notifications to your webhook endpoint for the following event types:
* `ledgerentry`
* `journalentry`
* `accounttransition`
* `accountstatement`
* `paymenttransition`
The Resend credit event notification endpoint reference has been added to the Account Transitions, Journal Entries, Ledger Entries, Statements, and Payments API reference pages. For example, you can view the [Resend credit event notification](/core-api/credit-account-transitions/#resend_webhook_event) reference in Account Transitions.
New features
##### PIN reveal functionality for widgets added to Marqeta.js library
The ability to display your cardholder’s PIN using a secure widget has been added to the Marqeta.js library. In many jurisdictions, such as the EU, cardholders are allowed to view their PIN in the event that they cannot remember what it is.
A cardholder’s PIN is considered Payment Card Industry (PCI) data, even when viewed separately from the card number and other associated card elements. Marqeta now provides the ability to view a PIN using a Marqeta.js widget for customers who are not PCI compliant. If you have been certified as PCI compliant, you can also access this functionality by making a `POST` request to the `/pins/reveal` endpoint of the [Core API](/core-api/pins/#reveal_pins).
To protect their PIN from unauthorized use, users must first authenticate to access their banking app, then authenticate again in order to reveal their PIN via the secure Marqeta.js widget.
Changed functionality
##### New transaction type in transaction payloads
The Marqeta platform now includes the `account.funding.authorization.clearing` transaction type in transaction payloads of JIT gateway requests, webhooks, and `GET /transactions` API requests.
Credit release 2022.11.28.0
New features
##### Minimum interest fee now appears as a single entry in statement summary
In cases where the configured minimum interest fee is greater than the calculated interest for a given cardholder, Marqeta now reports the single amount that is due, rather than separately reporting both the calculated interest fee and the adjustment required to meet the minimum interest fee.
For example, if the calculated interest is \$0.60, but the minimum interest fee is \$1.00, Marqeta will report only the actual interest charged, which is \$1.00.
##### Capping logic refactored to keep past due most severe
When reporting past due and minimum payment amounts in cases where their combined total exceeds the closing statement balance, Marqeta now caps the total of the two amounts to reflect the closing statement balance by reducing the minimum payment amount, rather than by reducing the past due amount.
For example, with a closing balance of \$80.00, a minimum payment amount of \$50.00, and a past due amount of \$35.00, the total must be capped at \$80.00 to reflect the closing statement balance. The capping logic introduced in this release has Marqeta reduce the minimum payment to \$45.00, instead of reducing the past due amount to \$30.00.
Credit release 2022.11.8.0
New features
##### Document policy available on the Marqeta Dashboard
In the Marqeta Dashboard’s Credit section, you can now view Document policy files when you select an active bundle. These files are classified as assets and templates.
Assets are the final disclosures, such as the Summary of Credit Terms (SOCT), Rewards Disclosure, Benefits Disclosure, Card Member Agreement (CMA), e-Disclosure, and Privacy Policy. Final disclosures contain custom, finalized values.
Templates are not final disclosures because they do not contain finalized values, but you can use them to review the static content.
Notable documentation changes
Added note about new lost or stolen card replacement workflow
A new workflow for replacing a lost or stolen card was introduced in the 2022.8.22.0 release, but was inadvertently excluded from the release notes. You can now see that release note at [New lost or stolen card replacement workflow](/developer-guides/release-notes-2022/#new-lost-or-stolen-card-replacement-workflow).
Relative to the [OpenAPI definition](https://raw.githubusercontent.com/marqeta/marqeta-openapi/main/yaml/CoreAPI.yaml) and the `AndroidPushTokenRequestAddress` schema, `phone_number` has been corrected and changed to `phone`. The corresponding [Digital Wallets Management](/core-api/digital-wallets-management/) API reference page now correctly includes `push_tokenize_request_data.user_address.phone`.
New Marqeta in Europe guides
There are two new [Marqeta in Europe](/developer-guides/marqeta-in-europe-landing-page/) guides.
* To learn about authorization, clearing, and settlement in Europe, see [Settlement and Reconciliation](/developer-guides/mq-eu-settlement-reconciliation/).
* To learn about error handling in Europe, see [Error Handling](/developer-guides/mq-eu-error-handling/).
As a way to offer you features and issue resolutions more quickly, in October 2022 the Marqeta platform switched from a semi-monthly release cadence to a weekly release cadence.
Contact your Marqeta representative for more information.
The 2022.10.31.0 release of the Marqeta platform contains infrastructure improvements and backend issue fixes only. There are no customer-facing enhancements or fixed issues in this release.
Changed functionality
##### Fixed: Mastercard pindebit transactions remained in pending state
This release of the Marqeta platform fixes an issue that caused Mastercard `pindebit.authorization.clearing` transactions to remain in the pending state even after they were cleared on the card network side.
##### New shipping methods
This release of the Marqeta platform includes two new values in the `shipping.method` field: `INTERNATIONAL_PRIORITY` and `LOCAL_PRIORITY`.
##### New fields for the create ACH transfer API
Two new optional fields have been added to the `POST /banktransfers/ach` endpoint:
* `channel`: Can have a value of either `API` or `SYSTEM`.
* `created_by`: Can be a string up to 255 characters. This field is required for transfers initiated through the Marqeta Dashboard.
For more information, see [Create ACH transfer](/core-api/funding-via-ach/#post_banktransfers_ach).
The 2022.10.17.0 release of the Marqeta platform contains infrastructure improvements and backend issue fixes only. There are no customer-facing enhancements or fixed issues in this release.
Changed functionality
##### New STIP reason code
To support the October 2022 and January 2023 VisaNet Business Enhancements article 4.2, Marqeta now includes a new stand-in processing (STIP) reason code in transaction payloads: `network_stip_card_lost_stolen`. This STIP reason code indicates that a transaction was declined by the Visa network during a STIP event because the card was reported lost or stolen.
##### New value for 3D Secure authentication status
To support the October 2022 and January 2023 VisaNet Business Enhancements article 3.8, Marqeta now includes a new `cardholder_authentication_data.authentication_status` value to indicate a successful non-payment authentication transaction: `SUCCESSFUL_NON_PAYMENT`.
For more information about the `cardholder_authentication_data` object, see [the Transactions response model](/core-api/transactions/#_response_body_3).
##### New values for 3D Secure authentication methods
To support the October 2022 and January 2023 VisaNet Business Enhancements article 3.8, Marqeta now includes new `cardholder_authentication_data.authentication_method` values: `BEHAVIORAL_BIOMETRICS`, `DECOUPLED`, `DELEGATED_TRUSTED_AUTHENTICATION`, `SECURE_PAYMENT_CONFM`, and `WEB_AUTHN`.
For more information about the `cardholder_authentication_data` object, see [the Transactions response model](/core-api/transactions/#_response_body_3).
##### New network metadata product identifiers
To support the October 2022 and January 2023 VisaNet Business Enhancements article 2.1, Marqeta now includes a new `network_metadata.product_id` value: `VISA_FLEXIBLE_CREDENTIAL`.
To support the October 2022 and January 2023 VisaNet Business Enhancements article 2.14, Marqeta now includes a new `network_metadata.product_id` value: `FLEXIBLE_RATE_B2B_VIRTUAL_PROGRAM`.
For more information about the `network_metadata` object, see [the Transactions response model](/core-api/transactions/#_response_body_3).
The 2022.10.03.0 release of the Marqeta platform contains infrastructure improvements and backend issue fixes only. There are no customer-facing enhancements or fixed issues in this release.
Notable documentation changes
New Partner Integrations page
Marqeta works with multiple product partners and platforms to provide you with a wide set of pre-built integrations, making it easier to get up and running with Marqeta. You can now learn about our partner integrations with Plaid, Mambu, and Kard on the [Partner Integrations](/developer-guides/partner-integrations/) page.
Added allowable fulfillment provider values
The [Card Products](/core-api/card-products/) API reference page now includes the following allowable `fulfillment_provider` values: `IDEMIA_FR_SC`, `GD`, `NITECREST_UK_SC`, `NITECREST_PL`, `TAG`, `IDEMIA_DE`, `FIS`, `CPI`, `EXCEET_DE`, `OBERTHUR_SC`, `IDEMIA_PE`.
New Marqeta in Europe guides
There are four new [Marqeta in Europe](/developer-guides/marqeta-in-europe-landing-page/) guides.
* Get information about what cardholder and card management in Europe entail in [Cardholder and Card Management](/developer-guides/mq-eu-cardholder-card-management/).
* Learn about the basics of transaction processing in Europe in [Transaction Processing](/developer-guides/mq-eu-transaction-processing/).
* Check out [Just-in-Time Funding](/developer-guides/mq-eu-jit-funding/) for details on how transaction processing and Just-in-Time Funding work in Europe.
* Review [Limits and Controls](/developer-guides/mq-eu-limits-controls/) to understand how to manage and maintain limits and controls in Europe through the Marqeta API.
New credit payment schedules API reference page
Use [payment schedules](/core-api/credit-account-payment-schedules/) to create and retrieve payment schedules on a credit account.
New credit reward redemption endpoint documentation
Use the new `/credit/rewardprograms/{token}/redemptions/{redemption_token}` endpoint to retrieve a specific redemption for a specific credit reward program. For the endpoint reference, see [Retrieve reward redemption](/core-api/credit-reward-redemptions/#get_redemption).
Added allowable credit statement cycle type
The [Credit Accounts](/core-api/credit-accounts/) reference page now includes `TRANSACTING` as an allowable `latest_statement_cycle_type` value.
The 2022.9.19.0 release of the Marqeta platform contains infrastructure improvements and backend issue fixes only. There are no customer-facing enhancements or fixed issues in this release.
New features
##### Birth date validation for cardholders and individuals associated with businesses
Marqeta now validates the date of birth of both cardholders and individuals associated with businesses. To enable birth date validation for your program, contact your Marqeta representative.
##### New Credit Journal Entries report
Use the new Credit Journal Entries report to view details of all journal entries for all credit accounts in a program, such as the status and amount. For details about this report in the Marqeta Dashboard, see [Reports in the Dashboard](/developer-guides/reports-dashboard/#_credit).
For details on using the DiVA API `GET /views/credit/journalentries/detail` endpoint to retrieve the journal entries, see [Credit journal entries](/diva-api/credit-journal-entries/).
##### New digital wallets web push provisioning endpoints
Use the new digital wallets web push provisioning endpoints to add payment cards to Apple Pay and Google Wallet via your web application. Note that these endpoints are currently in beta. For more information, see [Digital Wallets Management](/core-api/digital-wallets-management/).
Notable documentation changes
Improved information architecture for credit API reference pages
The [Core API](/core-api/introduction/) Credit documentation is now divided into several new categories, each pertaining to a specific Credit API: Credit Programs, Credit Account Origination, Credit Account Management, Credit Account Servicing, and Credit Reward Programs. This information architecture change makes it easier to find the Credit API reference documentation you are looking for.
You can find documentation for credit account APIs on these new reference pages:
* [Account Transitions](/core-api/credit-account-transitions/)
* [Account Cards](/core-api/credit-account-cards/)
* [Journal Entries](/core-api/credit-account-journal-entries/)
* [Ledger Entries](/core-api/credit-account-ledger-entries/)
* [Account Rewards](/core-api/credit-account-rewards/)
* [Statements](/core-api/credit-account-statements/)
* [Payments](/core-api/credit-account-payments/)
* [Adjustments](/core-api/credit-account-adjustments/)
* [Credit Disputes](/core-api/credit-account-disputes/)
* [Balance Refunds](/core-api/credit-account-balance-refunds/)
New credit application transition endpoint documentation
Use the new [application transition endpoint](/core-api/credit-applications/#_list_application_transitions) to retrieve an array of transitions on a specific application. Note that this endpoint is currently in beta.
Updated About Credit Accounts guide
The [Status](/developer-guides/about-credit-accounts/#_the_account_lifecycle) section of the [About Credit Accounts](/developer-guides/about-credit-accounts/) guide now includes the new `CHARGE_OFF` status for credit accounts, as well as a new infographic that presents credit account status transitions.
The About Credit Accounts guide also includes new information on [periodic fees and fee schedules](/developer-guides/about-credit-accounts/#_fees).
The [Reports In-depth](/developer-guides/reports-in-depth/#_credit) guide has been enhanced to include more information about Credit reports, such as the refresh rate.
Updated digital wallet names
The [Digital Wallets](/developer-guides/digital-wallets-landing-page/) documentation now uses the updated digital wallet names [Google Wallet](https://wallet.google/intl/en_us/) and [Samsung Wallet](https://www.samsung.com/us/samsung-wallet/).
Updated API reference documentation pages
Several API reference pages are now generated directly by parsing Marqeta’s API definition files in [OpenAPI](https://www.openapis.org/) format. This single-source approach ensures that the documentation remains synchronized with the API at all times.
You may therefore notice slight differences in the information architecture of this page:
* [Digital Wallets Management](/core-api/digital-wallets-management/)
New features
##### New lost or stolen card replacement workflow
You can now reissue a new primary account number (PAN) for a lost or stolen card in a single step. The new PAN is automatically associated with any existing digital wallet tokens for the lost or stolen card. Account updaters automatically inform the card network about the new PAN, allowing recurring payments to continue uninterrupted.
For information about the new workflow, see [Lost or stolen cards](/developer-guides/managing-lost-stolen-or-damaged-cards/#_lost_or_stolen_cards).
New features
##### Real-Time Decisioning now available
Real-Time Decisioning, part of Marqeta’s RiskControl fraud solution, is now in general availability (GA) release. Real-Time Decisioning provides fine-tuned control over card transactions using rules based on hundreds of data attributes, including the network risk score, spend amount, cardholder risk profile, merchant ID, and geolocation.
The Real-Time Decisioning dashboard provides an editor for writing and editing business rules using a dedicated language for fraud detection. The dashboard includes a wizard to generate business rules, tags, and variables, and to run offline unit tests. Real-Time Decisioning also includes an endpoint for reporting false positives. Learn more: [Real-Time Decisioning Overview](/developer-guides/real-time-decisioning-landing-page/).
##### New configuration of minimum program funding account balances for ACHO transfers
This release includes a new configuration for checking the minimum balance of a program funding account when initiating push transfers using ACH Origination. This configuration specifies the minimum allowed balance of the program funding account after the push transfer is approved. If the transfer would reduce the program funding account balance below the specified minimum, then the customer would receive the following error message:
```json JSON lines wrap theme={null}
{
"error_message" : "The requested Program ACH Origination PUSH would reduce the Program Reserve balance below the minimum required threshold of \$0.00"
}
```
For more information about configuring this feature, contact your Marqeta representative.
Notable documentation changes
##### New documentation set for Real-Time Decisioning
A new documentation set for the Real-Time Decisioning feature has been added, including several guides, references, and tutorials. See [Real-Time Decisioning Overview](/developer-guides/real-time-decisioning-landing-page/).
##### Powered By Marqeta in Europe guide moved
The [About Powered By Marqeta in Europe](/developer-guides/about-powered-by-marqeta-in-europe/) guide is now located in the [Marqeta in Europe](/developer-guides/marqeta-in-europe-landing-page/) collection.
##### New card products guide
To learn about Marqeta card products in Europe and their characteristics, see [Card Products](/developer-guides/mq-eu-card-products/).
##### New strong customer authentication guides
Learn about strong customer authentication (SCA) in Europe in the [About SCA in Europe](/developer-guides/mq-eu-about-sca/) guide. To learn about the technical requirements for strong customer authentication in Europe, see the [Managing SCA in Europe](/developer-guides/mq-eu-managing-sca/) guide.
##### New credit policies and bundles beta documentation
Learn about how to use the Marqeta Dashboard to manage your credit program’s policies and bundles in this new guide:
* [Credit Programs in the Marqeta Dashboard (Beta)](/developer-guides/credit-programs-dashboard/)
Although you must use the Marqeta Dashboard to manage policies and bundles, you can consult this new API documentation for reference purposes only:
* [Policies (Beta)](/core-api/credit-policies/)
* [Bundles (Beta)](/core-api/credit-bundles/)
##### New credit applications API reference page
Use the new applications endpoints to create and manage credit account applications and retrieve disclosures that you can show to an applicant during the application process. See this new API reference page:
* [Applications (Beta)](/core-api/credit-applications/)
##### In-depth information added for credit reports
Credit report details, which apply to both the Reporting dashboard and DiVA API, have been added to Reporting In-Depth. See [Reports In-Depth](/developer-guides/reports-in-depth/).
##### Updated report descriptions
Some report descriptions have been updated to reflect minor dashboard changes. See [Reports in the Dashboard](/developer-guides/reports-dashboard/) and [Reports In-Depth](/developer-guides/reports-in-depth/).
As a way to offer you features and issue resolutions more quickly, in July 2022 the Marqeta platform switched from a monthly release cadence to releasing biweekly.
Contact your Marqeta representative for more information.
New features
##### Specify amount limit for low-value payments with transaction risk analysis exemptions
You can now specify the maximum amount for a single low-value payment transaction with a transaction risk analysis (TRA) exemption in the `sca_tra_exemption_amount_limit` field of the `strong_customer_authentication_limits` object.
For detailed information about this field and the `strong_customer_authentication_limits` object, see the [Card Products](/core-api/card-products/) API reference page.
##### Support for "one-leg-out" transactions
"One-leg-out" (OLO) transactions are those in which a cardholder from a strong customer authentication (SCA) mandated country or region such as the United Kingdom or the European Union performs an e-commerce transaction with a merchant from a non-SCA mandated country, such as the United States. With this release of the Marqeta platform, if your program has enabled both SCA low-value payment (LVP) controls and the OLO exemption, Marqeta will not soft decline OLO transactions that have not been authenticated using 3D Secure.
The transaction response payloads of JIT requests, webhooks, and `GET /transactions` API requests indicate OLO transactions with a new field in the `transaction_metadata` object:
```json JSON lines wrap theme={null}
{
"transaction_metadata" : {
"one_leg_out" : true
}
}
```
To enable this feature, contact your Marqeta representative.
Changed functionality
##### New alpha-3 currency codes for Sierra Leone
Sierra Leone has redenominated their currency from the Leone to the New Leone. One New Leone is worth 1000 Leone.
To reflect this change, Visa has introduced new alpha-3 currency codes for Sierra Leone. The currency codes for the New Leone are `SLE` and `925`.
The existing alpha-3 codes for the Leone, `SLL` and `694`, are still supported, but all transactions in Sierra Leone currency must use the new currency codes beginning 1 October 2022.
New features
##### Reduced API latency across all platform endpoints
Marqeta is always optimizing systems for increased performance. With this release, Marqeta has reduced API latency by as much as 60% across all endpoints on the Marqeta platform.
Changed functionality
##### New fields in card acceptor object in transaction response payloads
The `card_acceptor` object in transaction response payloads now includes three new fields: `country_of_origin`, `transfer_service_provider_name`, and `payment_facilitator_name`. For detailed information about these new fields, see [Transactions](/core-api/transactions/).
##### Fees object now included in Gateway JIT transaction response payloads
Gateway JIT transaction response payloads now include the `fees` object along with the existing `acquirer_fee_amount` field to keep the data consistent with authorization webhook payloads.
Gateway JIT transaction response payloads now include the following details about fees:
```json JSON lines wrap theme={null}
{
"acquirer_fee_amount": 3,
"fees": [
{
"type": "PINDEBIT_ASSOC_FEE",
"amount": 3,
"credit_debit": "D"
}
]
}
```
##### Fixed: ATM balance inquiries rejected by the Marqeta platform
An issue that caused ATM balance inquiries to be rejected by the Marqeta platform has been resolved in this release.
##### Fixed: Gateway JIT fees did not match authorization webhook payloads
Gateway JIT messages now include the same fee data as the authorization webhook payloads for a given transaction.
New features
Public availability of OpenAPI 3.0 definitions
We are proud to announce the publishing of our OpenAPI 3.0 definitions in a dedicated, public GitHub repository: [https://github.com/marqeta/marqeta-openapi](https://github.com/marqeta/marqeta-openapi). Using these OpenAPI definitions, you can now build your SDKs and implement your product, based on the same source we use to generate our public documentation and APIs. This is an exciting next step toward improving our overall Developer Experience, and is part of our effort to create a single source of truth for our APIs.
Note that this is a beta release limited to our Core API endpoints, and that the work is ongoing. We would love to hear your [feedback](https://community.marqeta.com) if you use our definitions for testing or prototyping purposes.
Require identity verification step-up at the card product level
You can now require identity verification step-up ("yellow path" further information) for all digital wallets at the card product level by setting the new `force_yellow_path_for_card_product` field to `true`.
For information about the process for approving digital wallet tokens, see [Token approval process](/developer-guides/managing-the-digital-wallet-token-lifecycle/#_token_approval_process).
Changed functionality
ACH Origination transactions now include the bank transfer identifier
ACH Origination transactions now include the unique identifier of the bank transfer in the `bank_transfer_token` field of `GET /transactions` response bodies. The Marqeta Dashboard team uses this identifier to fetch detailed information about a given bank transfer.
3D Secure webhook events
The Marqeta platform now sends webhook events for 3D Secure 1.x and 2.x initialization and completion events. For information about 3D Secure webhook events, see [3D Secure transition events](/core-api/event-types/#_3d_secure_transition_events).
Service scalability and infrastructure are an ongoing goal for the Marqeta platform, and a recent optimization of our widgets infrastructure led to an incredible improvement in performance. The observed latency for widgets provisioning (p95) was reduced by almost half.
Fixed: JIT Funding fields missing from reversal transaction webhook payloads
An issue that prevented the `jit_funding.acting_user_token` and `jit_funding.user_token` fields from appearing in some reversal transaction webhook payloads has been fixed in this release.
Notable documentation changes
Help choosing between Swagger v2.0 and OpenAPI v3.0
A new section "Choosing an API definition file" was added to the [SDKs](/core-api/sdks-landing/) page to clarify the differences between the Marqeta platform’s Swagger v2.0 and OpenAPI v3.0 API definition files. For even more information, see [Marqeta’s blog post](https://community.marqeta.com/t5/engineering-blogs/marqeta-s-openapi-definitions-are-in-public-beta/ba-p/640) on the beta release of the platform’s OpenAPI definition.
New features
New field to support Mastercard article AN-4224
To support Mastercard article AN-4224, Marqeta now includes a new field in the transaction payload of Gateway JIT messages, webhooks, and `GET /transactions` requests that contains the details of a government-controlled merchant’s country-of-origin code. This new field is named `country_of_origin` and is included in the existing `card_acceptor` object.
A merchant’s country of origin can be different from the country in which the merchant is located. For example, embassies are physically located in countries that are not their country of origin: a Mexican embassy might be physically located in Singapore, but the country of origin is Mexico.
This field is included when the cardholder conducts a transaction with a government-controlled merchant using a Marqeta-issued card.
Tokenization-as-a-Service (Beta)
You can use Marqeta’s tokenization features for your program, even if Marqeta is not your issuer processor. For more information about tokenization as a service, see [Tokenization-as-a-Service (Beta)](/core-api/tokenization-as-a-service/).
New credit account journal entries
Learn about [credit account journal entries](/developer-guides/about-credit-account-journal-entries/), which are records of an entry made on a credit account journal, such as purchase transactions, fees, adjustments, and more. Journal entries are a newer version of ledger entries and replaces ledger entries.
The following journal entry endpoint references have been added to Credit Accounts:
* [List account journal entries](/core-api/credit-account-journal-entries/#list_account_journal_entries)
* [Retrieve account journal entry](/core-api/credit-account-journal-entries/#get_account_journal_entry)
* [List account statement journal entries](/core-api/credit-account-statements/#list_statement_journal_entries)
To learn about journal entry webhooks, see [Credit journal entry events](/core-api/event-types/#_credit_journal_entry_events).
Changed functionality
Breaking change for Account Funding and Original Credit Transactions
In previous releases, Marqeta included both the `original_credit` and `account_funding` objects in transaction payloads of JIT gateway requests, webhooks, and `GET /transactions` API requests, rather than including only the appropriate object for the transaction.
To address this issue, Marqeta changed the transaction payloads in this release to ensure that original credit transactions only include the `original_credit` object, and account funding transactions only include the `account_funding` object.
If your program receives either original credit or account funding transactions, be aware that your transaction payloads now incorporate this change.
Improved sample code blocks with enhanced syntax highlighting
The code block component used to display code examples throughout all collections of the Marqeta platform documentation has been enhanced with more meaningful syntax highlighting that better reflects the language of the code used in the example. The language name, such as `bash`, `JSON`, or `cURL`, now appears in the code block header. In the case of a longer code example that has been truncated, the number of hidden lines is displayed, allowing you to decide if you want to load the entire example.
Account verification transactions from blocked merchants and merchant categories now declined automatically
Account verification transactions, or "\$0 Auths", are now automatically declined if they are sent from blocked merchant category codes (MCCs) or merchant identifiers (MIDs). You can choose to add to an allow list any account verification transactions using specific MIDs from blocked MCCs, as you can for regular purchase transactions.
Changed network response codes to support Mastercard data integrity compliance
When you decline a transaction with a `decline_reason` of `CLOSED_ACCOUNT`, Marqeta now sends the network response code `14: JIT Response Closed Account` to Mastercard.
This change minimizes use of the `05 - Do not honor` response code to support data integrity compliance.
Corrected network response code for soft declines due to missing customer authentication
When you decline a transaction with a `decline_reason` of `SOFT_DECLINE_AUTHENTICATION_REQUIRED`, Marqeta now sends the correct network response code `1A - Additional customer authentication required` to Visa.
Removed ALL as an allowable value of the Transaction Model
The `ALL` state for individual transaction objects has been removed from the Transaction Model. `ALL` is still an allowable value in `GET` requests to the [/transactions](/core-api/transactions/) endpoint.
Fixed: card\_acceptor object was included in gpa.credit.authorization payloads
An issue that caused the `card_acceptor` object to appear in `gpa.credit.authorization` payloads has been fixed in this release.
Fixed: MoneySend transactions declined due to invalid service code
An issue that caused some MoneySend transactions to be declined due to an invalid service code has been fixed in this release. This issue impacted a small number of Mastercard MoneySend transactions. These transactions will no longer be declined due to a service code mismatch.
Changed how credit users subscribe to card transition and digital wallet token transition events
Credit users no longer receive credit card transition and credit digital wallet token transition events by subscribing to `credit.*`. For more on how to subscribe to these events, see [Card transition events](/core-api/event-types/#_card_transition_events) and [Digital wallet token transition events](/core-api/event-types/#_digital_wallet_token_transition_events).
Notable documentation changes
Updated API reference documentation pages
Several API reference pages are now generated directly by parsing Marqeta’s API definition files in [OpenAPI](https://www.openapis.org/) format. This single-source approach ensures that the documentation remains synchronized with the API at all times.
You may therefore notice slight differences in the information architecture of this new page:
* [Program Funding via ACH (Beta)](/core-api/funding-via-ach/)
New features
New response code for declined card present JIT Funding transactions
The Marqeta platform now applies the transaction response code `1918 – JIT response soft decline PIN required` to card present transactions that are declined at the point of sale because the cardholder’s PIN was not entered.
New response code for refund.authorization transactions
The Marqeta platform now applies transaction response code `1922 Transaction cannot be completed` to credit voucher and merchandise return authorization (`refund.authorization`) transactions. Response code `1922` is applied to any `refund.authorization` transaction that is declined for a reason other than `INVALID_MERCHANT`, `INVALID_AMOUNT`, `INVALID_CARD`, `CLOSED_ACCOUNT`, or `SUSPECTED_FRAUD`.
New response codes for declined transactions
The Marqeta platform now applies transaction response codes `1919 Card terminated`, `1920 Cardholder terminated`, and `1921 Digital wallet terminated` to transactions that are declined due to a termination.
New fields to support Visa article 3.2
To support Visa’s article 3.2 data standards for original credit transactions (OCT), the Marqeta platform now includes the `transfer_service_provider_name` and `payment_facilitator_name` fields in the `card_acceptor` object in transaction webhooks, JIT Funding messages, and `GET /transactions` payloads.
New product codes and field to support Mastercard article AN4777
To support Mastercard article AN 4777, the Marqeta platform now includes Mastercard installment payment product codes in the `product_id` field of the `network_metadata` object in clearing transaction webhooks. The new product codes are:
* `ETA`: Mastercard Installment Payments A
* `ETB`: Mastercard Installment Payments B
* `ETC`: Mastercard Installment Payments C
* `ETD`: Mastercard Installment Payments D
* `ETE`: Mastercard Installment Payments E
* `ETF`: Mastercard Installment Payments F
* `ETG`: Mastercard Installment Payments G
* `SPP`: Mastercard Installment Payments P
* `SPS`: Mastercard Installment Payments S
In addition to these new product codes, the Marqeta platform now passes the Mastercard-assigned merchant identification numbers in the `network_assigned_id` field of the `card_acceptor` object in transaction response payloads. You can use the `network_assigned_id` to perform analytics based on the Mastercard-assigned merchant identifiers for your installment programs.
Added support for ATM deposits for Mastercard MoneySend Payment Transactions
Mastercard offers a domestic cash-to-card capability that allows cardholders to add cash to Debit Mastercard and Maestro cards at cash deposit-taking ATMs in Switzerland. When Marqeta receives ATM cash deposits as Original Credit Transactions (OCT), the Marqeta platform now populates the `transaction_type` under the `original_credit` object with a `cash_in` value.
Introduction of Mastercard’s Account Intelligence (AI) for Issuers
Mastercard has introduced a new feature called Account Intelligence (AI) for Issuers: Fraud and Risk solution to issuers in Europe. The AI for Issuers solution includes a set of 15 AI-powered scores that cover three key portfolio management themes, and will be delivered to issuer customers in First Presentment (`1240`) messages. The Marqeta platform now provides the solution’s AI data in the clearing webhook’s `fraud` object, as shown below.
```json JSON lines wrap theme={null}
"fraud": {
"network_account_intelligence_score": {
"service_type": "string", // Position (1-2)
"name": "string", // Position (3-4)
"value": "string" // Position (5-7)
}
}
```
Using these scores can provide dynamic insights into your cardholder portfolio and drive account-level risk management through smarter decisioning. At time of writing, these scores have been introduced in the United States, EU, and Canada.
Contact your Marqeta representative to learn more about this optional feature, including fees, and enable it for your program.
Added account funding object to transaction payloads
To support Visa article 3.9, the Marqeta platform now includes the `account_funding` object in transaction response payloads of JIT Funding messages, webhooks, and `GET /transactions` API requests.
Allowable `account_funding.transaction_type` values for Visa account funding transactions are:
`account_to_account` `money_transfer_by_bank` `funds_transfer` `face_to_face_merchant_payment` `person_to_person` `prepaid_loads` `wallet_transfer` `disbursement` `pension_disbursement`
The JSON model of the `account_funding` object is:
```json JSON lines wrap theme={null}
"transactions:" {
"account_funding": {
"transaction_type": "string",
"transaction_purpose": "string",
"receiver_name": "string",
"screening_score": "string"
}
}
```
New reporting data freshness indicator
Relevant reports in the Marqeta Dashboard now display a data freshness indicator indicating how recently the data was updated, with additional information available as a tooltip. For information on this feature, see [Data freshness indicator](/developer-guides/reports-dashboard/#_data_freshness_indicator).
A new field, `report_load_timestamp`, has been added to key endpoints in the DiVA API to provide programmatic access to data freshness information. You can configure your automated jobs to trigger based on updates to this field. For information on this field, see [Automating jobs based on updates](/diva-api/exploring-the-diva-api/#_automating_jobs_based_on_updates).
Changed functionality
Secure electronic commerce transactions in transaction payloads
The Marqeta platform now includes secure electronic commerce transactions in transaction payloads with an `electronic_commerce_indicator` value of `authentication_successful` and a `verification_result` value of `not_present`.
Fixed: Issue displaying amounts in transaction payloads for Iceland Krona
An error in displaying the `original_amount` in the transaction payload for currency code `352 - Iceland Krona` has been fixed on the Marqeta platform.
Notable documentation changes
Multi-language support for code examples
Multi-language support has been added to the codeblock component used to display code examples throughout all collections of the Marqeta platform documentation. Available languages are indicated in the upper-left corner of the component.
The inline API widgets used throughout all collections of the Marqeta platform documentation and the API Explorer now feature the full payload with sample data in the request body. The shape of the schema is shown, but only fields marked as required are presented. This enhancement makes it easier to interact with the API using copy/paste operations.
Updated API reference documentation pages
Several API reference pages are now generated directly by parsing Marqeta’s API definition files in [OpenAPI](https://www.openapis.org/) format. This single-source approach ensures that the documentation remains synchronized with the API at all times.
You may therefore notice slight differences in the information architecture of these new pages:
* [Business Transitions](/core-api/business-transitions/)
* [Businesses](/core-api/businesses/)
* [Commando Mode](/core-api/commando-mode/)
* [KYC Verification](/core-api/kyc-verification/)
* [Transactions](/core-api/transactions/)
* [User transitions](/core-api/user-transitions/)
* [Users](/core-api/users/)
* [Velocity Controls](/core-api/velocity-controls/)
New features
Upcoming breaking change: correct payload for AFT/OCT transactions
Marqeta currently includes both the `original_credit` and `account_funding` objects in transaction payloads through JIT gateway requests, webhooks, and `GET /transactions` API requests, rather than including only the appropriate object for the transaction type.
To address this issue, Marqeta will change the transaction payloads to ensure that original credit transactions only include the `original_credit` object, and account funding transactions only include the `account_funding` object.
If you receive either original credit or account funding transactions, be aware that your transaction payloads will incorporate this change in the May 2022 release.
New ACH reports
New ACH reports are available in the Marqeta Dashboard and DiVA API:
* ACH Gateway – Details on ACH gateway activity.
* ACH Origination – Transaction-level detail for ACH Origination transfers for both Program Funding and User Funding use cases.
* ACH Pending – Details on pending ACH gateway activity.
* ACH Verification – Verification details on ACH gateway activity.
These reports are available in the Reports dashboard under **Other Transactions > ACH** and **Other Transactions > ACH Origination** and in the DiVA API. For more on these reports in the dashboard, see [Other transactions reports](/developer-guides/reports-dashboard/#_other_transactions). For more on the DiVA endpoints, see [DiVA API Reference](/diva-api/introduction/).
Changed functionality
Changes to response codes for credit voucher and merchandise return authorization transactions
To support article 2.8 of the VisaNet Business Enhancement effective April 2022, Marqeta requires a change to your JIT gateway decline response codes for credit voucher and merchandise return authorization transactions (both represented by the `refund.authorization` transaction type on the Marqeta platform).
Beginning in release 22.3, your JIT gateway should only use these codes in the `decline_reason` field when declining `refund.authorization` transactions:
* `INVALID_MERCHANT`
* `INVALID_AMOUNT`
* `INVALID_CARD`
* `CLOSED_ACCOUNT`
* `SUSPECTED_FRAUD`
If your JIT gateway declines `refund.authorization` transactions with a `decline_reason` not included in the preceding list, Visa would usually reject that authorization response from the Marqeta platform and process the transaction using stand-in processing (STIP). To avoid processing these transactions in STIP, Marqeta will now respond to Visa with response code `93 - Transaction cannot be completed` whenever we decline transactions for any reason other than the ones listed above.
For more information about Gateway JIT response codes, see [JIT Funding responses](/core-api/gateway-jit-funding-messages/#_jit_funding_responses).
Card product token added to transaction payload
The card product token is now included at the root level in the transaction payload of JIT requests, webhooks, and `GET` requests to the `/transactions` endpoint.
The card product token associated with the card used in the transaction will be returned for all transaction types—including declined transactions—provided the card is present in the Marqeta platform.
Using the card product token, you can quickly obtain additional configuration details from the Marqeta platform and make timely, better informed responses to JIT requests.
For more information about card products and how they determine card functionality and behavior, see the [Card Products](/core-api/card-products/) API reference page.
Acquiring identifier now included in clearing webhooks
Marqeta now includes the six-digit acquiring identifier in the `institution_id_code` field of the `acquirer` object in clearing webhooks. You can use this code to associate refunds with their original authorizations.
For more information about this object and field, see [Transactions](/core-api/transactions/).
New program-level authorization check
A program-level check has been added to the Marqeta platform to ensure that only programs with the ACH Origination feature or the Plaid Account Verification feature enabled are able to make API calls to the endpoints listed below:
* `POST` requests to `/v3/fundingsources/ach/partner`
* `POST` requests to `/v3/banktransfers/ach`
* `GET` requests to `/v3/banktransfers/ach`
* `GET` requests to `/v3/banktransfers/ach/{token}`
* `GET` requests to `/v3/banktransfers/ach/transitions`
Contact your Marqeta representative to enable and configure these features.
For more information about moving funds over the ACH network using the Marqeta platform, see the [Program Funding via ACH](/core-api/funding-via-ach/) API reference page. To learn more about how to use Plaid as a third-party partner for validating your account holders, see [Account Validation via Plaid](/developer-guides/account-validation-via-plaid/).
Fixed: Declined transactions excluded from database (auth-service only)
In previous releases, the Marqeta platform would occasionally not commit declined transactions to the database for auth-service customers during periods of high load. This behavior has been resolved in Marqeta platform release 22.3 by queueing affected messages so they are added asynchronously.
For an overview of transactions and the `transaction` object, see [About Transactions](/developer-guides/about-transactions/).
Fixed: Incorrect parsing of 3D Secure authentication exemption data from Mastercard
An issue that prevented the `cardholder_authentication_data.acquirer_exemption` field of the transaction payload from being properly populated has been resolved in Marqeta platform release 22.3. This field indicates the reason why the acquirer made a 3D Secure authentication exemption such as `MERCHANT_INITIATED_TRANSACTION` or `LOW_VALUE_PAYMENT`; it is only returned when it is included in the transaction data received from the card network.
For detailed information about the `cardholder_authentication_data` object and the `acquirer_exemption` array, see [Transactions](/core-api/transactions/).
Fixed: Incorrect velocity control balance calculation
This release of the Marqeta platform resolves a double-impacting velocity control issue that occurred while issuing online refunds. In previous releases, the Marqeta platform would deduct refund amounts twice (once when the refund came to adjust the velocity control balance, and again during clearing for the same refund to update the `velocity_control_cache` database table).
For more information about how to use velocity controls to oversee spending by your cardholders, see the [Controlling Spending](/developer-guides/controlling-spending/) guide.
Changes to reports
The Program Funding Balances report replaces the Reserve Balances report. Use this report to get a daily aggregated view of a program’s funding balance using an authorization funding model. The report is available in the Reports dashboard under **Balance > Program Funding Balances** and in the DiVA API. For information on this report in the dashboard, see [Balance reports](/developer-guides/reports-dashboard/#_balance). For information on the DiVA endpoint, see [Program Funding Balances](/diva-api/program-funding-balances/).
Notable documentation changes
Updated API reference documentation pages
Several API reference pages are now generated directly by parsing Marqeta’s API definition files in [OpenAPI](https://www.openapis.org/) format. This single-source approach ensures that the documentation remains synchronized with the API at all times.
You may therefore notice slight differences in the information architecture of these new pages:
* [Account Holder Funding Sources](/core-api/account-holder-funding-sources/)
* [Addresses](/core-api/addresses/)
* [Balances](/core-api/balances/)
* [Cards](/core-api/cards/)
* [Card Transitions](/core-api/card-transitions/)
* [PINs](/core-api/pins/)
* [Program Funding Sources](/core-api/program-funding-sources/)
* [Program Gateway Funding Sources](/core-api/program-gateway-funding-sources/)
* [Webhooks](/core-api/webhooks/)
Changed functionality
New field for details on acquirer-exempted transactions meets EU requirement
For e-commerce transactions, acquirer exemptions are now supported and included in the `cardholder_authentication_data` object. This additional field provides details on acquirer-exempted transactions, including merchant-initiated transactions, which are exempted from cardholder authentication.
Acquirer-exempt transaction reporting is required in the EU region, and this data will help provide needed details for the regulators. The information is provided in the `acquirer_exemption` field, which is now converted from a string to an array in the `cardholder_authentication_data` object.
The transaction payload will contain information as follows:
```json JSON lines wrap theme={null}
"cardholder_authentication_data":
{
"acquirer_exemption" : [
"TRANSACTION_RISK_ANALYSIS",
"MERCHANT_INITIATED_TRANSACTION"
]
}
```
Mastercard OCT transactions no longer require CVC in the request
The Marqeta platform no longer enforces a requirement that OCT transactions using Mastercard include the CVC in the request. Furthermore, such transactions are no longer declined.
Refund authorizations no longer declined for terminated or suspended digital wallet tokens
For `refund.authorization` transactions, the Marqeta platform now allows refunds to go through successfully, even if the digital wallet token is in a terminated or suspended state.
The Marqeta platform now includes expanded definitions of the `shippinginformationresponse` object used by the API Explorer and the Core API inline widgets to correctly include `FEDEX_EXPEDITED`, `FEDEX_REGULAR`, `UPS_EXPEDITED`, `UPS_REGULAR`, `USPS_EXPEDITED`, `USPS_REGULAR`, `LOCAL_MAIL`, `LOCAL_MAIL_PACKAGE`, `GROUND`, `TWO_DAY`, `OVERNIGHT`, and `INTERNATIONAL` in addition to the previously supported responses as part of the `fulfillment.shipping` object.
Fixed declined transactions that include foreign currencies
An issue that caused the Marqeta platform to decline balance inquiry transactions when a foreign currency was present in the request has been fixed on the Marqeta platform.
Updated requirements for reason codes on declined transactions
The Marqeta platform now includes updated the reason codes we provide to Visa for declined transactions to align with recently released data integrity standards. When the JIT Funding gateway responds to a JIT Funding request and denies requested funding, you should provide an appropriate `decline_reason` so that Marqeta can in turn respond to the network with the correct network response codes. For details, see the `decline_reason` field [documentation](/core-api/gateway-jit-funding-messages/) on Gateway JIT Funding Messages.
Ability to modify Discretionary Data in Card Products API
With this release, Card Products API users can now modify values for `Track 1` and `Track 2` stored in Discretionary Data in order to capture additional information at the point of sale for fleet use cases.
The full object structure now looks as shown below:
```json JSON lines wrap theme={null}
{
"config":{
"poi":{
"other":{
"track1_discretionary_data": "000015",
"track2_discretionary_data": "00015"
}
}
}
}
```
Notable documentation changes
New guide for integrating with Plaid
Learn step-by-step how to [integrate with Plaid](/developer-guides/account-validation-via-plaid/) to validate your users in this new guide available in the Transactions category of the Guides collection. This guide links to a new endpoint used to create an ACH source via a partner integration, which is featured in the [Account Holder Funding Sources](/core-api/account-holder-funding-sources/#post_fundingsources_ach_partner) API reference page.
New Building Your Card Program guides
We have introduced new Building Your Card Program guides, including an [Understanding Card Program Differences](/developer-guides/understanding-card-program-differences/) guide that compares the Powered By Marqeta (PxM) and Managed By Marqeta (MxM) card program models. This guide helps you decide if you want to learn more about [Building Your Powered By Marqeta Card Program](/developer-guides/building-your-powered-card-program/) or [Building Your Managed By Marqeta Card Program](/developer-guides/building-your-managed-card-program/).
New Powered By Marqeta in Europe guide
There is a new [About Powered By Marqeta in Europe](/developer-guides/about-powered-by-marqeta-in-europe/) guide that offers integration overview information.
New features
Automatic card suspension after successive card-not-present (CNP) verification failures
To help prevent fraudulent CNP transactions, you can choose to automatically suspend cards after a configurable number of successive CVV2 or CVC2 verification failures.
Talk to your Marqeta representative to enable and configure this feature.
3D Secure acquirer exemptions for e-commerce transactions
Marqeta now provides details about merchant-initiated e-commerce transactions that are exempt from the 3D Secure cardholder authentication requirements in the `acquirer_exemption` array within the `cardholder_authentication_data` object in transaction response payloads.
You can use this data to comply with EU reporting regulations for acquirer-exempted transactions.
For detailed information about the `cardholder_authentication_data` object and the `acquirer_exemption` array, see [Transactions](/core-api/transactions/).
New verification result value for cardholder authentication data in STIP advice messages
The `cardholder_authentication_data.verification_result` field in stand-in processing (STIP) advice messages now supports the enumerated value `not_verified_authentication_outage` to indicate when stand-in processing was triggered by a 3D Secure authentication outage.
For detailed information about the `cardholder_authentication_data` object, see [Transactions](/core-api/transactions/).
Changed functionality
The PCI-compliant [Activate Card and Set PIN Widgets](/developer-guides/using-activate-card-and-set-pin-widgets/) have been redesigned to reflect takeaways collected from recent usability research:
* The user experience when entering a PAN as part of activating a card has been improved for enhanced readability and retention. Previously, the card number display was formatted as `1111222233334444`; now card numbers are displayed in groups of four digits such as `1111 2222 3333 4444`.
* Where appropriate, the widgets' input fields will now display a number dial pad instead of a full QWERTY keyboard.
* A legibility issue whereby the overlay spinner impeded visibility while processing a card activation or set PIN request has been addressed.
Webhook password strength conditions
A series of validation checks for the password used to access your [webhook endpoint](https://app.marqeta.com/development/add-webhook) have been added to the public/private sandbox environment. These checks ensure that each of the password strength conditions is evaluated in real time by the [Marqeta Dashboard](https://app.marqeta.com/). A checkmark ( ✓ ) indicates when the condition has been satisfied, and the **Save** button only becomes enabled once all conditions have been met. For more information on creating webhooks in the public/private sandbox environment, see the [Manage your webhooks](/developer-guides/control-center-dashboard/#_developer_tools) section of the [Dashboard Overview and Quick Start](/developer-guides/dashboard-overview-and-quick-start/).
Shortened public sandbox provisioning time
The Marqeta platform provides a secure testing and development environment called the [sandbox](https://sandbox-api.marqeta.com/v3) where you can explore the capabilities of the Core API. A reduction in dependency management tools has enabled us to dramatically shorten the time required to provision a public sandbox from 10 minutes to only three minutes. To create your own public sandbox and user, [sign up for an account](https://www.marqeta.com/users/sign_up) on the Marqeta platform.
Nested deposit\_account object no longer returned in response body
In previous versions, a successful `POST` request to the `/users` or `/businesses` endpoint would include a nested `deposit_account` object in the response body. This object has been withdrawn from the response body of both endpoints, as it was unneeded and could create confusion.
Example of the previous response body:
```json JSON expandable lines wrap theme={null}
{
"token": "my_user_01",
"active": true,
"gender": "F",
"first_name": "Jane",
"last_name": "Doe",
"email": "jane.doe6@company.com",
"address1": "1234 Grove Street",
"city": "Berkeley",
"state": "CA",
"zip": "94702",
"country": "USA",
"phone": "5105551212",
"uses_parent_account": false,
"ssn": "___________",
"corporate_card_holder": false,
"password": "___________",
"created_time": "2022-01-16T20:21:24Z",
"last_modified_time": "2022-01-16T20:21:24Z",
"metadata": {},
"account_holder_group_token": "DEFAULT_AHG",
"status": "ACTIVE",
"deposit_account": { // Object that is no longer returned
"token": "b176f7d5-8f8c-4c60-b486-5716365c9fda",
"account_number": "40015554000146410",
"routing_number": "293748000",
"allow_immediate_credit": false
},
"birth_date": "1991-01-01"
}
```
New response body, without the nested `deposit_account` object:
```json JSON expandable lines wrap theme={null}
{
"token": "my_user_01",
"active": true,
"gender": "F",
"first_name": "Jane",
"last_name": "Doe",
"email": "jane.doe6@company.com",
"address1": "1234 Grove Street",
"city": "Berkeley",
"state": "CA",
"zip": "94702",
"country": "USA",
"phone": "5105551212",
"uses_parent_account": false,
"ssn": "___________",
"corporate_card_holder": false,
"password": "___________",
"created_time": "2022-01-16T20:21:24Z",
"last_modified_time": "2022-01-16T20:21:24Z",
"metadata": {},
"account_holder_group_token": "DEFAULT_AHG",
"status": "ACTIVE",
"birth_date": "1991-01-01"
}
```
Fixed: Zero-dollar authorizations for inactive cards
An issue that caused zero-dollar authorizations on inactive cards to return a `Card is active` message has been fixed in this release.
## Related topics
- [2023 Release Notes](/docs/developer-guides/release-notes-2023.md)
- [Release Notes](/docs/developer-guides/release-notes.md)
- [2024 Release Notes](/docs/developer-guides/release-notes-2024.md)
- [2021 Release Notes](/docs/developer-guides/release-notes-2021.md)