2021 Release Notes

Webhooks enable public sandbox users to configure and manage notifications about API events. You can now use the Marqeta Dashboard to create and modify webhook configurations for the sandbox environment associated with your account. You can also use it to subscribe to any number of event listeners you need for your transactions workflow. In previous releases, configuring webhooks required sending requests to the /webhooks endpoint of the Core API.

For more information on configuring webhooks, see the Access developer tools section of the Dashboard Overview and Quick Start.

The Approval queue in Credit Programs in the Marqeta Dashboard allows those with creator and approver roles to view a list of credit products that are in review or revision. For more on the Approval queue, see Approval queue in the Managing Credit Programs in the Marqeta Dashboard guide.

Those with the creator role for Credit Programs in the Marqeta Dashboard can now edit active credit products. Prior to this update, creators could only edit credit products in draft. For more on editing credit products, see the Editing a credit product tutorial in the Managing Credit Programs in the Marqeta Dashboard guide.

Several API reference pages are now generated directly by parsing Marqeta’s API definition files in OpenAPI 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:

Note that the Orders page has been renamed to GPA Orders. In addition, the Transfers page has been divided into three shorter pages (Fee Transfers, Peer Transfers, and Program Transfers) to make it easier to find information related to a specific kind of transfer.

Marqeta’s Credit program is no longer in beta. To learn more about activating a Credit program with Marqeta, contact your Marqeta representative.

The transaction payload in webhooks, JIT Funding requests, and GET /transactions operations includes cardholder authentication data for Mastercard e-commerce transactions beginning in Marqeta platform release 21.11.

For detailed information about the cardholder authentication data in transaction payloads, see the cardholder_authentication object in Transactions.

Beginning in release 21.11, the Marqeta platform now supports a new LIMITED state for cards. In the LIMITED state, a card is temporarily non-functional except for card-on-file transactions such as installment payments or recurring charges.

For more information about card states, see the The card lifecycle.

To comply with card network mandates, card-not-present transactions declined due to invalid card security codes receive the new response code 1915: Invalid CVV2 in transaction webhooks beginning in Marqeta platform release 21.11.

In previous releases, declined card-not-present transactions triggered response code 1825: Invalid CID. Card security code is invalid; CVV does not match. Marqeta will continue to use code 1825 for declined card-present transactions.

For more information about transaction response codes including code 1915, see transaction response codes.

Beginning in Marqeta platform release 21.11, account funding transaction data is available by default in webhooks, JIT Funding requests, and GET /transactions operations.

For detailed information about account funding transaction data, see the account_funding object in Transactions.

Inaccurate data provided by acquirers resulted in declined transactions because Visa could not validate the cardholder authentication verification value (CAVV) correctly.

This issue is fixed in Marqeta platform release 21.11. Marqeta can now overwrite the CAVV validation result from Visa. Contact your Marqeta representative to enable this fix for your card program.

Performance and throughput are significantly improved for DiVA API and Reports users. Average response times in particular are nearly three times faster with the implementation of DiVA API V2 Scaled.

A variety of infrastructural changes were implemented to enhance overall security and address outstanding vulnerabilities.

The legacy version of DiVA API V2 had a maximum concurrency of 12 users or queries at a single time. DiVA API V2 Scaled supports up to 1,000 concurrent requests, allowing the service to scale gracefully over time.

Ascending or descending sorts can now be performed on individual fields. By default, fields sort in ascending order. Placing a minus sign (-) in front of a field changes its sort order to descending.

For example, sort_by=-transaction_date,account_id is interpreted as ORDER BY transaction_date DESC, account_id ASC. Changing the parameters to sort_by=-transaction_date,-account_id would sort both fields in descending order, interpreted as ORDER BY transaction_date DSC, account_id DESC.

Previously, any - in the sort_by string caused the final field to be sorted in descending order and all other fields in ascending order.

How responses are reported when a timeout occurs has changed. { "message": "Endpoint request timed out" } is now returned with HTTP 504. The timeout duration has been reduced from 60 seconds to 30 seconds. Use asynchronous or download requests for long running queries, such as applying async=true to your call.

The fields acting_uai, parent_uai, and user_uai are now handled more consistently. For example, the string 000000000 is now returned as 0 in the JSON response. This addresses a bug that potentially caused the last several digits of these fields to be modified in large requests.

The calculation of start_date and end_date response fields returned with query results have changed. For more about DiVA metadata and query results, see Response field details.

The start_date field is now calculated using the returned records instead of the filter used to retrieve them. This represents the minimum value of the datetime field used to filter the list of returned records. If multiple datetime filters are used, both are applied but start_time is calculated using only the first filter. Previously, this was echoing the provided filter’s start date.

The end_date field is now calculated using the returned records instead of the filter used to retrieve them. This represents the minimum value of the datetime field used to filter the list of returned records. If multiple datetime filters are used, both are applied but end_time is calculated using only the first filter. Previously, this was echoing the provided filter’s end date.

Learn about credit account ledger entries on the Marqeta platform in About Credit Account Ledger Entries.

You can now retrieve the lineage of a credit product using the /credit/products/{token}/lineage endpoint. To learn more, see Retrieve credit product lineage.

Several API reference pages are now generated directly by parsing Marqeta’s API definition files in OpenAPI 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:

CVV2 and CVC2 codes are three-digit validators for cards issued by Visa and Mastercard, respectively. These validators are used during card-not-present transactions to reduce fraud.

Beginning with Marqeta platform release 21.10, Marqeta sends a new transaction response code: 1915: Invalid CVV2 for transactions where the CVV2 or CVC2 code is invalid.

For more information about transaction response codes, see transaction response codes.

Beginning in Marqeta platform release 21.10, the original_credit object includes the deferred_hold_by field when original credit transactions are deferred by either the acquirer or Visa. This field is included to support changes Visa has made to deferred original credit transaction (OCT) processing. You can see the deferred_hold_by field in the original_credit object of JIT Gateway messages and webhooks, as well as in the response body of calls made to the GET /transactions endpoint.

For detailed information about this new field, see the original_credit object in Transactions.

Visa now requires issuers in Europe to support the Acceptance Environment Authentication Outage indicator field and values. The Acceptance Environment Authentication Outage indicator is used to show that authentication was attempted for a transaction but there was an outage in the authentication flow between the merchant, gateway 3D Secure server, and the Visa Directory Server. In such cases, authentication requests fail.

To support Visa’s Acceptance Environment Authentication Outage indicator, the Marqeta platform includes new enumerated value not_verified_authentication_outage in the cardholder_authentication_data.verification_result field beginning in Marqeta platform release 21.10.

For detailed information about this new enumerated value, see the cardholder_authentication_data object in Transactions.

Mastercard now lets merchants use MoneySend Payments to issue faster refunds. Participating merchants can inform cardholders that funds will be available in near real time on either the card that was used for the original purchase transaction or on a different card.

Beginning in Marqeta platform release 21.10, the Marqeta platform includes two new enumerated values for the original_credit.transaction_purpose field to indicate a MoneySend Payments refund: refund_to_original_card and refund_to_new_card.

For detailed information about these new enumerated values, see the original_credit object in Transactions.

Point-of-sale (POS) terminals support offline processing for transactions made, for example, while aboard an airplane or during a service maintenance window, as well as for transactions impacted by technological interruptions such as inclement weather. Mastercard now indicates such deferred authorizations to inform issuers when authorization requests are sent on a deferred basis to explain any discrepancy between the time that the transaction occurred and the time that the authorization request was received.

To support Mastercard’s deferred authorization indicators, the Marqeta platform includes the is_deferred_authorization field in the transaction_metadata object in webhooks and in the response body of calls made to the GET /transactions endpoint, beginning in Marqeta platform release 21.10.

For detailed information about the is_deferred_authorization field, see the transaction_metadata object in Transactions.

Marqeta 3D Secure (3DS) is now certified to process Mastercard 3DS 2.2.0 requests from merchants. The new message protocol offers all the benefits of 2.1.0, plus more flexibility and control over strong customer authentication (SCA) exemptions and the authentication experience. To participate in Mastercard 3DS 2.2.0, you must enroll your bank identification number (BIN) ranges for 2.2.0 with Mastercard and enable 3DS 2.2.0 on the Marqeta Dashboard.

For more information about Mastercard 3DS 2.2.0 processing, contact your Marqeta representative.

The API Keys page of the Marqeta Dashboard has been redesigned to reflect takeaways collected from recent usability research. Knowing what is available within the public sandbox and what to do with your API keys once you have them is a common stumbling block for new developers. Among the improvements made to the page are descriptions of what assets are provisioned in the public sandbox environment (such as a default card product) and a new sample request formatted within a code block that supports multiple programming languages.

The Authorization Controls API reference page is now generated directly from the feature’s OpenAPI specification, ensuring that the documentation remains synchronized with the API at all times. You may notice some slight differences in the information architecture of the new page.

Learn about the interactions and dependencies of Marqeta’s credit-related Core API resources. See Summary of Credit Resources.

Beginning in Marqeta platform release 21.9, the transaction payload in webhooks, JIT Funding requests, and GET /transactions operations can now include an account_funding object to capture details about account funding transactions on the Mastercard network. If you want to receive these enhanced account funding transaction details, contact your Marqeta representative.

For detailed information about the account_funding object, see Transactions.

Beginning in Marqeta platform release 21.9, the transaction payload in webhooks, JIT Funding requests, and GET /transactions operations now includes the following additional merchant details in the card_acceptor object:

For detailed information about these new fields, see the card_acceptor object Transactions.

Beginning in Marqeta platform release 21.9, you can use alphanumeric merchant identifiers (MIDs) on the /merchantgroups endpoint, rather than strictly numeric MIDs.

For detailed information about /merchantgroups MIDs, see Merchant Groups.

Beginning in Marqeta platform release 21.9, when an automated teller machine (ATM) transaction is declined but an ATM fee is incurred, Marqeta sends these fees to you in webhooks and Gateway JIT Funding messages. ATM fees for declined transactions are typical in regions outside the United States of America.

ACH transactions can be returned for a variety of reasons, and support for several new ACH return codes has been added to the Marqeta platform beginning in Marqeta platform release 21.9. To view all supported codes, see the reason_code field in the Direct Deposits API reference page.

The Marqeta platform provides a private testing and development environment called the sandbox where you can explore the capabilities of the Core API. The sandbox creation process has recently been rearchitectured for increased speed and reliability. To create your own public sandbox and user, sign up for an account on the Marqeta platform.

Beginning in Marqeta platform release 21.9, the ability to allow cardholders to set a personal identification number (PIN) during the first transaction with their new card (the allow_first_pin_set_via_financial_transaction field in the config.transaction_controls object) has been deprecated, and will be removed in a future release.

For more information, see the config.transaction_controls object.

See how to manage credit account payments using the Marqeta platform, in About Credit Account Payments.

Learn about the newly added account_funding object for Mastercard transactions, as well as three additional fields for the card_acceptor object (payment_facilitator_id, independent_sales_organization_id, and sub_merchant_id). See Transactions.

Over in the Marqeta Knowledge Base there’s a new write-up about using webhooks on our platform, including a detailed walkthrough. See How to use Marqeta Webhooks.

You can now transition users from Active to Unverified. See Create user transition and The account holder lifecycle.

The Marqeta Developer Community is a place where developers can engage directly with us (and each other) to share best practices, tips, and solutions. This new channel includes a forum, knowledge base, engineering blogs, and much more. We expect this community will grow into a vibrant hub where developers can make meaningful connections, share ideas, and learn from the experiences of others building on top of the Marqeta platform.

If your program registers to use the Early Pay feature, you can manually transition direct deposit transactions to APPLIED before the settlement date and make your cardholder’s funds available up to two days faster. To do this, send a POST request to /directdeposits/transitions.

A new error code (400280) is returned if a program that has not registered to use the Early Pay feature attempts to transition a direct deposit to APPLIED before the settlement date. This same error code is returned when attempting to transition an ineligible transaction such as a debit. If you see this error, simply wait until the settlement date to proceed with the transition. To access the settlement date for a transaction, send a GET request to /directdeposits/{token}.

Visa has implemented changes to modify response codes used during stand-in processing to provide descriptive values that identify the primary reason for the transaction decline.

Beginning in Marqeta platform release 21.8, Marqeta has made an enhancement to ensure it is able to receive new values in authorization response and advice messages and support Visa’s use case.

The 3D Secure (3DS) Advanced Authentication flow has been enhanced to allow the authentication screen to be automatically submitted when a cardholder completes authentication in a mobile banking app.

This enhancement eliminates a step that required the cardholder to go back to the authentication screen and click the Done button. It is intended to reduce cardholder transaction abandonment.

Some acquirers do not parse lowercase characters in 3DS cardholder authentication verification value (CAVV) data, replacing those characters with zeroes. This causes a mismatch of CAVV data which in turn leads to transactions being declined by VISA. Beginning in Marqeta platform release 21.8, the Marqeta platform changes all lowercase characters in CAVV data to uppercase before sending it to the network to avoid mismatches and allow transactions to be approved as expected.

In previous versions, the Marqeta platform added two extra zeroes to zero-exponent currency values in the original_amount field of clearing webhooks, which caused a mismatch between the authorization and the clearing amounts. Beginning in Marqeta platform release 21.8, Marqeta now uses the correct format in this field so clearing and authorization amounts for zero-exponent currencies match correctly.

In previous versions, the Marqeta platform marked refund authorizations declined by stand-in processing (STIP) as authorizations rather than refund authorizations, resulting in incorrect transaction data. Beginning in Marqeta platform release 21.8, these declined refund authorizations now show the correct transaction type.

The full list of transaction response codes has been validated and updated.

See About Credit Account Statements.

See Managing Credit Programs in the Marqeta Dashboard.

The following events are added:

You can use the /banktransfers endpoint to initiate funds movement between your program funding account and an external account over the ACH Network. For more information about this kind of bank transfer, also known as ACH origination, see Program Funding via ACH (Beta).

Beginning in Marqeta platform release 21.7, the phone field is now an optional field for /businesses objects, rather than a required field.

Beginning in Marqeta platform release 21.7, Mastercard transaction response data in GET /transactions, webhooks, and Gateway JIT Funding messages now includes stand-in processing (STIP) advice codes and descriptions when they are provided by the card network. See the advice_reason_code and advice_reason_details field documentation in Transactions.

Learn how the credit account dispute process works, including provisional credits in About Credit Account Disputes (Beta).

See the new /createBalanceRefund endpoint in the Credit Accounts API reference.

Learn about Marqeta’s implementation of Automated Clearing House (ACH) origination and what happens when an originator enters an ACH transaction into the ACH payments system on behalf of the receiver in ACH Origination.

See how to use a transfer to move funds entirely within the Marqeta platform in Program Funding via ACH (Beta).

See how to use merchant groups for authorization controls and in card product configurations in Merchant Groups.

Several additions and updates have been made to the Mastercard and Visa Disputes documentation, including:

See the following:

Added a new page with detailed report information. See Reports In-depth.

Updated schema descriptions to include the Core API Transaction Token for the following DiVA API endpoints.

The Card Program Requirements guide is updated and consolidated in Building Your Card Program.

Beginning in Marqeta platform release 21.6, you can use the /merchantgroups endpoint to create groups of merchants by their merchant identifier. With merchant groups, you can, for example, exempt groups of merchants from certain transaction types, such as quasi-cash transactions. To learn more, see the Merchant Groups Core API reference page.

Beginning in Marqeta platform release 21.6, Gateway JIT messages include additional decline reasons. Merchants can use these additional decline reasons to better help cardholders take the appropriate action to complete a transaction. See the decline_reason field documentation on the Gateway JIT Funding Messages page.

Beginning in Marqeta platform release 21.6, transaction payloads include the is_preauthorization field to indicate if a transaction is a pre-authorization. See the is_preauthorization field documentation in Transactions for more information.

Beginning in Marqeta platform release 21.6, 3D Secure acquirer exemptions are available for Mastercard transactions in the transaction payload. See the cardholder_authentication_data.acquirer_exemption field documentation in Transactions for more information.

Have you been thinking about trying out Marqeta’s open API platform to create a customized card program, but don’t know where to begin? Our latest webinar, Getting started with Marqeta APIs, walks you through spinning up a card program prototype then testing it using simulated transactions in a public sandbox environment. You’ll also see a demo of updates to our dev tools like the Transaction Timeline. After 60 minutes, you will know how to get started with Marqeta and begin building your own card experiences with our open APIs.

We added an API reference page for the POST /credit/accounts/{token}/payments endpoint to the Credit Accounts API.

See overviews of the concepts used in payment card programs on the Payment Cards Concepts page. Some of this content was previously found on the Money Movement Overview page.

Does your program support 3D Secure? In this Tech Brief, read all about how Marqeta’s 3D Secure solution helps card programs fight online fraud without compromising the user experience.

Marqeta’s customizable widgets enable your cardholders to securely interact with your customer applications in compliance with the Payment Card Industry Data Security Standard (PCI DSS). Beginning in Marqeta platform release 21.5, the widgets offer support for five additional languages: French (France), Spanish, Italian, Swedish, and German, which complement the existing language set of English (US), Polish, French (Canada), and Czech. More descriptive error messages have also been added to all supported languages.

See the newly published API reference doc for Payment Sources and new endpoints published in the API reference doc for Credit Accounts, both products currently in beta: Credit Overview. See the Credit Reporting API reference docs and the Credit Reports in the Marqeta Dashboard guide, also currently in beta: DiVA API Credit Reference and Marqeta Dashboard Report Types.

Beginning in Marqeta platform release 21.5, you can view Mastercard SecureCode AAV verification results for e-commerce transactions in Gateway JIT messages, transaction webhooks, and in GET /transactions. You must have a Mastercard BIN configured with On-behalf Service (OBS) 05 or 06 to receive the relevant result codes. See the cardholder_authentication_data.verification_result field documentation for more information: Transactions.

Beginning in Marqeta platform release 21.5, you can view multi-currency transaction settlement data for clearing transactions in Gateway JIT messages, transaction webhooks, and in GET /transactions. See the currency_conversion.network.settlement_data object documentation for more information: Transactions.

The Transaction Timeline tool enables users of the Marqeta public sandbox to better understand the role of transactions in their integration and the broader payments space. This release of the Transaction Timeline tool applies to all public sandbox accounts with the Developer role and provides the following enhancements:

Beginning in Marqeta platform release 21.5, Marqeta sends more accurate response codes to Visa for transactions declined due to invalid cards, inactive digital wallet tokens, and inactive cardholders. Your cardholders may see more specific decline messages at points of sale due to this change.

Beginning in Marqeta platform release 21.5, you can overwrite the Cardholder Authentication Verification Value received from Visa. This change allows you to make your own cardholder verification decisions if you do not want to rely solely on the verification results from Visa. See the cardholder_authentication_data.verification_result field documentation for more information: Transactions.

Beginning in Marqeta platform release 21.5, Marqeta uses the new transaction response code 1901: Card not activated to indicate declined transactions due to unactivated cards. Terminated cards continue to return transaction response code 1806: Card not active for declined transactions. For more information, see transaction response codes.

Beginning in Marqeta platform release 21.5, the capacity of the list of exempted merchant identifiers for quasi-cash transactions has been increased from 15 to 100. For more information about configuring quasi-cash exempt merchant identifiers, see The config.transaction_controls object.

An issue that caused all merchant-initiated transactions for amounts over the strong customer authentication low-value payment limit to be declined has been resolved in Marqeta platform release 21.5.

The Push-to-Card Payments API reference documentation has been updated with new field names and descriptions.

Transactions is updated with new fields and descriptions.

We newly published a reference doc for the Payment Sources endpoint, which lets you manage an external payment source for a credit account holder: Payments Sources. The Credit Accounts reference adds ten new endpoints, and the Credit Products is also updated.

Beginning in Marqeta platform release 21.4, digital wallet token card art is configured at the card product level. This feature is useful for consumer card programs that include multiple versions of card art. It also enables Marqeta to update the card art and other metadata for the tokenized card whenever that card is reissued, rather than only when the token is first issued.

See the Digital Wallet Tokenization object.

Beginning in Marqeta platform release 21.4, authorization transactions include settlement data for multi-currency transactions if that data is provided by the card network. Settlement data is included in the currency_conversion.network.settlement_data object.

See Transactions.

To support Visa Article 2.7 — Changes to Credit Voucher and Merchandise Return Authorization Processing, Marqeta only allows response codes that are applicable to these transaction types, beginning in Marqeta platform release 21.4. No action is required from you to accommodate this change.

Beginning in Marqeta platform release 21.4, clearing webhooks include the enhanced_data_token field. Values in this field will be used to associate clearing transactions with enhanced commercial card data (level 2 and level 3 data) in a future Marqeta release.

Beginning in Marqeta platform release 21.4, the state fields in businesses objects now accept spaces. For example, New York rather than NewYork.

Beginning in Marqeta platform release 21.4, Mastercard transactions performed at partial-approval capable point-of-sale terminals now include standin_by and standin_approved fields in webhook payloads and GET /transactions responses.

An issue that caused international ATM access fees to be excluded from transaction payloads has been resolved in Marqeta platform release 21.4.

An issue that caused zero-exponent currencies, such as Japanese Yen ( ¥ ), to be formatted incorrectly has been resolved in Marqeta platform release 21.4.

We added overviews of the docs that help you use Marqeta services. Example: Cards.

See newly published API reference docs and guides for Credit Products and Credit Accounts, both products currently in beta: Credit Overview.

There is new guidance for KYC verification failures and clarification of fictitious business names/DBAs: KYC Verification.

See About associated transactions and Submit a batch of possibly associated transactions.

The v1.1.0 release of the Marqeta.js library restores support for the Copy to Clipboard feature. Using this feature, you can build seamless, modern user experiences that enable your cardholders to copy sensitive card information to their device’s clipboard in a single click while still maintaining PCI compliance.

Although the previous version of Marqeta.js is still currently available, it is recommended to upgrade to v1.1.0 in order to continue supporting all major browsers. For details on both versions of the library, see Using Marqeta.js.

Beginning in Marqeta platform release 21.3, Marqeta captures extended stand-in processing codes for Visa transactions. This change went into effect on April 18, 2021.

Beginning in Marqeta platform release 21.3, Marqeta supports business-to-business transfers over Mastercard MoneySend.

Beginning in Marqeta platform release 21.3, Marqeta includes the transaction_purpose field for single- and dual-message Mastercard MoneySend transactions. This field contains information about the purpose of the transaction if such information is captured by the merchant and sent to the card network.

Marqeta has improved how the output of the /v3/swagger.json endpoint is validated, enabling you to generate SDKs for your integration. By programmatically validating for structural errors such as duplicate operationId values, we can confidently release an OpenAPI specification to production that won’t break your codebase. Note that this enhanced validation does not include checking for semantic errors.

Beginning in Marqeta platform release 21.3, Marqeta removes personally identifiable information (PII) from digital wallet token transaction messages to better comply with the terms of service for both Apple and Google.

This change is currently opt-in only, and will be gradually rolled out to all Marqeta customers over time. For more information about this change, contact your Marqeta representative.

An issue that caused STIP transactions on the Maestro card network to be processed as financial advice messages is resolved in Marqeta platform release 21.3. Marqeta processes Maestro STIP transactions as standard single message authorizations with additional STIP details.

An issue that caused incorrect AVS responses for cards issued in the United Kingdom has been resolved in Marqeta platform release 21.3.

Marqeta’s developer documentation now has a central landing page called Home that provides an overview of all available content and directs you to pertinent resources in fewer clicks. The homepage makes it even easier to find the relevant Developer-facing content you are looking for, such as Guides, API Reference pages, SDKs, and the API status.

Newly published! The entire Marqeta Transaction response model, for the first time, here: Transactions.

See About Customer Due Diligence.

See Using the Marqeta.js v1.1.0 Library.

See Configuring low-value e-commerce payment limits.

Includes a more detailed process with a new dispute lifecycle diagram. See The Dispute Lifecycle.

See Disputes.

Beginning in Marqeta platform release 21.2, you can configure low-value payments (LVP) e-commerce limits for strong customer authentication (SCA) at the card product level. These configuration options support compliance with the PSD 2 regulatory technical standards article 16 for your card issuance region.

Upon reaching the limits you have configured, the Marqeta platform requires cardholders to authenticate themselves before attempting additional transactions.

For more information, contact your Marqeta account representative and see the strong customer authentication limits documentation.

Beginning in Marqeta platform release 21.2, the 3D Secure advanced authentication screen displays the time remaining for a cardholder to authenticate, helping cardholders respond in a timely manner and reducing the transaction abandonment rate.

Beginning in Marqeta platform release 21.2, you can exempt specific merchants from the quasi-cash transaction authorization control by configuring exemptions at the card product level.

For more information, contact your Marqeta account representative and see the transaction controls documentation.

An issue that caused the payment_channel to contain a different value in authorization and clearing webhooks for a given transaction has been resolved in Marqeta platform release 21.2.

An issue that caused some authorizations to be processed as incremental has been resolved in Marqeta platform release 21.2.

An issue that caused some mail order/telephone order transactions to be captured incorrectly during clearing transactions has been resolved in Marqeta platform release 21.2.

An issue that caused incorrect currency codes to be returned when customers performed ATM balance inquiries has been resolved in Marqeta platform release 21.2. This issue was experienced by cardholders whose accounts held balances in multiple currencies.

Beginning in release 21.1, the Marqeta platform provides the following new features to support PSD2 compliance:

Beginning in release 21.1, the Marqeta platform captures and stores acquirer exemption reasons for Mastercard e-commerce transactions to support future reporting.

Beginning in Marqeta platform release 21.1, the Marqeta platform includes the acquirer reference number in clearing webhooks for Visa and Mastercard transactions. The acquirer reference number is a 23-digit string that appears in the acquirer_reference_data field in the webhook payload.

Beginning in Marqeta platform release 21.1, the Marqeta platform uses an updated HTTP client for better performance. The new HTTP client helps alleviate some HSM timeout issues.

Beginning in Marqeta platform release 21.1, transactions originated using cards on file are no longer declined by Marqeta for missing CVV2/CVC2 data.

Marqeta platform release 21.1 resolves an issue that caused mismatches between the values of the payment_channel field in the authorization payload and the clearing payload for a given transaction.

Marqeta platform release 21.1 resolves an issue that caused some authorizations to be incorrectly processed as incremental.

Marqeta platform release 21.1 resolves an issue that caused some mail order/telephone order indicators to be captured incorrectly in clearing transactions.

Marqeta platform release 21.1 resolves an issue that caused refunds for child cardholders not to be applied to the parent cardholder when the uses_parent_account flag was true and child cardholder was in an inactive state.