Release Notes

The Core API 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:

Use the new application transition endpoint to retrieve an array of transitions on a specific application. Note that this endpoint is currently in beta.

The Status section of the 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.

The Reports In-depth guide has been enhanced to include more information about Credit reports, such as the refresh rate.

The Digital Wallets documentation now uses the updated digital wallet names Google Wallet and Samsung Wallet.

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 this page:

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. 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 if you use our definitions for testing or prototyping purposes.

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.

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.

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.

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.

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.

A new section "Choosing an API definition file" was added to the SDKs 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 on the beta release of the platform’s OpenAPI definition.

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.

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

Learn 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:

To learn about journal entry webhooks, see Credit journal entry events.

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.

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

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.

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.

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

An issue that caused the card_acceptor object to appear in gpa.credit.authorization payloads has been fixed in this release.

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.

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 and Digital wallet token transition events.

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 this new page:

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.

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.

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.

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.

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:

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.

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.

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.

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.

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:

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.

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.

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.

An error in displaying the original_amount in the transaction payload for currency code 352 - Iceland Krona has been fixed on the Marqeta platform.

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.

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:

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 are available in the Marqeta Dashboard and DiVA API:

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. For more on the DiVA endpoints, see DiVA API Reference.

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:

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.

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 API reference page.

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.

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:

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

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.

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.

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

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. For information on the DiVA endpoint, see Program Funding Balances.

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:

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:

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.

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.

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.

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 on Gateway JIT Funding Messages.

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:

Learn step-by-step how to integrate with 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 API reference page.

We have introduced new Building Your Card Program guides, including an 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 or Building Your Managed By Marqeta Card Program.

There is a new About Powered By Marqeta in Europe guide that offers integration overview information.

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.

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.

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.

The PCI-compliant Activate Card and Set PIN Widgets have been redesigned to reflect takeaways collected from recent usability research:

A series of validation checks for the password used to access your webhook endpoint 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. 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 section of the Dashboard Overview and Quick Start.

The Marqeta platform provides a secure testing and development environment called the sandbox 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 on the Marqeta platform.

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:

New response body, without the nested deposit_account object:

An issue that caused zero-dollar authorizations on inactive cards to return a Card is active message has been fixed in this release.