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.

For transactions where the CVV2 or CVC2 code is invalid, Marqeta now sends a new transaction response code: 1915: Invalid CVV2.

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

The original_credit object now 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 could 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 the transaction field descriptions section of the Transactions API reference page.

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 now includes a new enumerated value in the cardholder_authentication_data.verification_result field: not_verified_authentication_outage.

For detailed information about this new enumerated value, see the cardholder_authentication_data object in the transaction field descriptions section of the Transactions API reference page.

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.

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 the transaction field descriptions section of the Transactions API reference page.

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 now 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.

For detailed information about the is_deferred_authorization field, see the transaction_metadata object in the transaction field descriptions section of the Transactions API reference page.

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 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 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 (Beta).

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 the transaction field descriptions.

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 in the transaction field descriptions.

You can now use alphanumeric merchant identifiers (MIDs) on the /merchantgroups endpoint, rather than strictly numeric MIDs.

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

When an automated teller machine (ATM) transaction is declined but an ATM fee is incurred, Marqeta now 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. 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 sandbox and user, sign up for an account on the Marqeta platform.

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 (Beta).

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 Transaction field descriptions.

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.

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 the cardholder 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. The Marqeta platform now 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. 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. 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 (Beta).

See Managing Credit Programs in the Marqeta Dashboard (Beta).

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).

The phone field is now an optional field for /businesses objects, rather than a required field.

For Mastercard transactions, 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 the transaction field descriptions for more information.

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 (Beta) 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.

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.

Gateway JIT messages now 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.

Transaction payloads now include the is_preauthorization field to indicate if a transaction is a pre-authorization. See the is_preauthorization field documentation in the transaction field descriptions for more information.

3D Secure acquirer exemptions are now available for Mastercard transactions in the transaction payload. See the cardholder_authentication_data.acquirer_exemption field documentation in the transaction field descriptions 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 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). The widgets now 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.

You can view Mastercard SecureCode AAV verification results for eCommerce 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: Transaction field descriptions.

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: Transaction field descriptions.

The Transaction Timeline tool enables Marqeta sandbox users 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 sandbox accounts with the Developer role and provides the following enhancements:

Marqeta now 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.

You can now 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: Transaction field descriptions.

Marqeta now 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.

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.

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

The Transaction response is updated with new fields and descriptions.

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

Digital wallet token card art is now 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.

Authorization transactions now 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 transaction field descriptions.

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

Clearing webhooks now 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.

The state fields in businesses objects now accept spaces. For example, New York rather than NewYork.

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.

An issue that caused zero exponent currencies, such as Japanese Yen ( ¥ ), to be formatted incorrectly has been resolved.

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.

Marqeta captures extended stand-in processing codes for Visa transactions. This change goes into effect on April 18, 2021.

Marqeta supports business-to-business transfers over Mastercard MoneySend.

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.

We have 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.

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. 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.

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.

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.

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.

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.

An issue that caused some authorizations to be processed as incremental has been resolved.

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

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

The Marqeta platform provides the following new features to support PSD2 compliance:

The Marqeta platform captures and stores acquirer exemption reasons for Mastercard e-commerce transactions to support future reporting.

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.

The Marqeta platform uses an updated HTTP client for better performance. The new HTTP client helps alleviate some HSM timeout issues.

Transactions originated using cards on file are no longer declined by Marqeta for missing CVV2/CVC2 data.

This release 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.

This release resolves an issue that caused some authorizations to be incorrectly processed as incremental.

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

This release 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.

The new Transaction Timeline tool has been added to all sandbox accounts. The Transaction Timeline tool helps newcomers to the Marqeta platform quickly understand the role played by transaction flows in their integration, as well as in the broader payments space. It demonstrates line-by-line how individual transactions impact each other, and how they affect the account balance.

After simulating at least one transaction in your sandbox, access the Transaction Timeline by logging into the Marqeta Dashboard. Enter one of your card tokens in the Transaction Timeline to generate a history of all the transactions completed on that card.

Expedited shipping and expedited processing time are configured independently when fulfilling card orders:

When ordering cards from Arroweye Solutions, you can select from the following generic shipping options:

These options specify shipping companies and services available from the card provider. They were previously available only from Perfect Plastic Printing and IDEMIA.

For details on which shipping companies and services are offered by each card provider, contact your Marqeta representative.

The Docs site has undergone a top-to-bottom design update that aligns it with Marqeta’s current aesthetic, as seen in the Marqeta Dashboard and elsewhere. The fresh look-and-feel includes design components, colors, fonts, and other elements. The site’s content and organization remain unchanged.

The API Explorer has been updated to use a new custom API widget that is already available in Core API reference pages. The enhanced interactive widget resolves a major issue whereby endpoints with required query parameters did not behave as expected.