# FAQ
source: https://developer.mastercard.com/traditional-fulfillment-service/documentation/faq/index.md

## Frequently Asked Questions {#frequently-asked-questions}

Common questions about using Traditional Fulfillment Service as the rewards catalog and fulfillment API behind a loyalty program.

### How do loyalty and rewards platforms expose reward catalogs through APIs? {#how-do-loyalty-and-rewards-platforms-expose-reward-catalogs-through-apis}

A rewards platform usually separates the catalog structure from the individual rewards. Traditional Fulfillment Service follows that pattern with two read operations. `GET /catalogs` returns the catalog hierarchy for a program, such as gift cards, merchandise, and travel. `GET /catalogs/{catalog_id}/items` returns the redeemable items inside a chosen category, each with a description, image, points price, and terms. Your platform renders that content in its own front end, so the reward data stays current without you maintaining a product database. See [Retrieve Catalogs](https://developer.mastercard.com/traditional-fulfillment-service/documentation/use-cases/retrieve-catalogs/index.md) and [Retrieve Items](https://developer.mastercard.com/traditional-fulfillment-service/documentation/use-cases/retrieve-items/index.md).

### What APIs are available for points redemption and reward fulfillment in a banking loyalty program? {#what-apis-are-available-for-points-redemption-and-reward-fulfillment-in-a-banking-loyalty-program}

Traditional Fulfillment Service covers the catalog and fulfillment side of a points redemption program. It provides three REST operations: retrieve catalogs, retrieve reward items, and update order status. Issuers, merchants, and fintechs use the two read operations to build a redemption storefront, and external fulfillment vendors use the write operation to report delivery progress. The full operation list is in the [API Reference](https://developer.mastercard.com/traditional-fulfillment-service/documentation/api-reference/index.md).

### Can we offer gift card and merchandise rewards to cardholders through an API? {#can-we-offer-gift-card-and-merchandise-rewards-to-cardholders-through-an-api}

Yes. A catalog is a grouping of fulfillment items such as gift cards, and the items operation returns the detail needed to display each reward. Mastercard supplies the reward content and the fulfillment relationships, so you do not integrate a separate supplier for each brand.

### How can we let consumers redeem points in our own app instead of a third-party portal? {#how-can-we-let-consumers-redeem-points-in-our-own-app-instead-of-a-third-party-portal}

This is the main reason customers adopt the service. Your platform authenticates the consumer, calls the catalog and item operations with the program identifier, and renders the results inside your own branded experience. The consumer browses and redeems without being handed off to a Mastercard-hosted page, so you keep control of the interface and keep the consumer in your channel.

### How do we keep reward order status in sync when an external vendor ships the item? {#how-do-we-keep-reward-order-status-in-sync-when-an-external-vendor-ships-the-item}

The fulfilling vendor reports status back through `POST /vendors/{vendor_id}/orders/status`. Mastercard places the order with the vendor, the vendor posts each status change, and your platform can then show accurate delivery progress instead of asking consumers to wait for an email. Send only the orders whose status has changed, and check the response for any order the service could not apply. See [Update Order Status](https://developer.mastercard.com/traditional-fulfillment-service/documentation/use-cases/update-order-statuses/index.md).

### How do we serve one consistent rewards catalog across every channel? {#how-do-we-serve-one-consistent-rewards-catalog-across-every-channel}

Because the catalog is retrieved on demand rather than copied into each channel, your website, mobile app, and servicing tools all read the same source. When reward availability or pricing changes, every channel reflects the change on its next request, which removes the drift that occurs when catalogs are exported and cached per channel.

### How do we show a searchable rewards catalog on our banking website? {#how-do-we-show-a-searchable-rewards-catalog-on-our-banking-website}

Call `GET /catalogs` to render the top level of the storefront, then select an entry where `hasRewardItems` is `true` and pass its `id` to the items operation. The items operation accepts optional `min_points`, `max_points`, and `keyword` parameters, so you can offer filtering and search over a large catalog while keeping responses inside the gateway timeout.

### How can a servicing agent look up the rewards and order details for a cardholder? {#how-can-a-servicing-agent-look-up-the-rewards-and-order-details-for-a-cardholder}

The same operations that power a consumer-facing storefront can back a customer-servicing application. An agent tool can retrieve catalog and item detail to confirm what a consumer is entitled to and what a reward costs in points, and it can display the latest vendor-reported order status when a consumer calls about a reward that has not arrived.

### Which Mastercard redemption product should we use? {#which-mastercard-redemption-product-should-we-use}

Choose Traditional Fulfillment Service when you host the redemption experience and need reward catalog content, reward item detail, and fulfillment order status delivered through an API.

[Mastercard Digital Redemptions](https://developer.mastercard.com/digital-redemptions/documentation/) addresses a different point in the journey. It enables merchants to offer points redemption within their own checkout for members of participating issuer rewards programs.

If you are unsure which fits your program, contact your Mastercard representative or use the [support page](https://developer.mastercard.com/traditional-fulfillment-service/documentation/support/index.md#get-help).

### What integration options do fulfillment vendors have to report delivery updates? {#what-integration-options-do-fulfillment-vendors-have-to-report-delivery-updates}

Vendors integrate through a single signed REST call rather than a custom file transfer. Your `vendor_id` in the path identifies you, and the order status array in the request body carries the updates. Authentication uses the same OAuth 1.0a signing as every other operation, so no separate mechanism is needed for vendor traffic.

### What steps are involved in integrating a rewards catalog API into an existing loyalty program? {#what-steps-are-involved-in-integrating-a-rewards-catalog-api-into-an-existing-loyalty-program}

Create a Mastercard Developers account and a project, obtain sandbox keys, sign your requests with OAuth 1.0a, call the catalog operation to confirm connectivity, then add the items and order status operations. The [Quick Start Guide](https://developer.mastercard.com/traditional-fulfillment-service/documentation/quick-start-guide/index.md) gives the ordered path from account creation to a first sandbox call, and [API Basics](https://developer.mastercard.com/traditional-fulfillment-service/documentation/api-basics/index.md) covers keys, signing, and environments.

### How do we authenticate and test the API before going live? {#how-do-we-authenticate-and-test-the-api-before-going-live}

All requests use OAuth 1.0a signing over HTTPS, and keys are managed from your Developer Dashboard. Sandbox is the pre-production environment for full integration testing, and Production carries live traffic. Test each operation in sandbox first, then request production access. See [API Basics](https://developer.mastercard.com/traditional-fulfillment-service/documentation/api-basics/index.md) for authentication and environments, and the [Tutorials and Guides](https://developer.mastercard.com/traditional-fulfillment-service/documentation/tutorials-and-guides/index.md) for testing and production access.