Radial Gr4vy Integration

Radial Gr4vy is a payment orchestration platform that simplifies payment processing and provides a unified API for multiple payment methods and gateways.

Overview

Gr4vy enables merchants to:

• Process payments through multiple gateways
• Support various payment methods (credit cards, digital wallets, etc.)
• Manage payment configurations without code changes
• Reduce PCI compliance scope with secure fields
• Tokenize payment methods for future use

Key Features

Payment Methods Supported

• Credit and Debit Cards (Visa, MasterCard, American Express, Discover)
• Digital Wallets (Apple Pay, Google Pay, PayPal, Venmo)
• Alternative Payment Methods
• Gift Cards

Integration Types

• Secure Fields: PCI-compliant iframe-based integration
• Direct API: Direct integration for alternative payment methods
• SDKs: Frontend and backend SDKs available

Getting Started

1. Obtain your API credentials from Radial
2. Configure your sandbox and production environments
3. Choose your integration method (Secure Fields or Direct API)
4. Follow the integration guide specific to your merchant account

Documentation

For general integration information for Gr4vy please see the following link: https://radial.mintlify.app/guides/get-started

For detailed specific integration instructions, please access your merchant-specific integration guide. If you forget your access code please contact your account manager.

Migrating From Radial to Gr4vy: Mapping Payment Response Codes

This document helps a merchant migrating from Radial to Gr4vy preserve existing business logic by mapping Radial’s payment response codes to Gr4vy’s transaction statuses and error codes.radial+1

High‑level concepts

Radial

Radial’s credit‑card APIs return a business‑oriented response code on authorization, plus AVS/CVV/processor details.

Key auth response codes include:

• APPROVED – Authorization approved.
• DECL, DECLF, DECLR – Authorization declined (generic, lack of funds, lost/stolen).
• AVS, CSC, AVSCSC – Address/CVV problems.
• PaymentProcessorTimeout – No response from processor.

Gr4vy

Gr4vy exposes:

• A transaction status, e.g. authorized, authorization_declined, authorization_error.
• A normalized error_code, e.g. issuer_decline, service_decline, service_network_error, service_error.
• Optional raw/detail fields: raw_response_code, avs_response_code, cvv_response_code.

Your migration task is to translate existing “if Radial code = X then do Y” rules into “if Gr4vy status/error_code = A then do B”. [docs.gr4vy]

2. Core auth result mapping

2.1 Summary table

From a merchant‑behavior perspective, this is the closest conceptual mapping:gr4vy+2

Note: Gr4vy does not expose Radial’s APPROVED/DECL/... strings directly; instead it normalizes them into its own small set of error_code values and exposes raw detail separately.gr4vy+1

3. Mapping specific Radial codes to Gr4vy behavior

This section assumes you previously had logic based directly on Radial’s auth response codes.

3.1 APPROVED

Radial: APPROVED – Authorization approved. Gr4vy equivalent:

• status = "authorized".[docs.gr4vy]

Recommended behavior:

• Keep existing “success” behavior: create order, reserve inventory, move to fulfillment.

Pseudocode:

text
if gr4vy.status == "authorized":
    accept_order()

3.2 DECL / DECLF / DECLR (issuer declines)

Radial:[docs.radial]

• DECL – General decline.
• DECLF – Decline due to lack of funds/credit.
• DECLR – Decline due to card reported lost/stolen.

Gr4vy equivalent:

• status = "authorization_declined"
• error_code = "issuer_decline" (issuer refused) or refused_transaction depending on operation.gr4vy+1

Recommended behavior (similar to Radial):

• Prompt shopper to use a different card or payment method.
• Optionally, allow limited retries on the same card (e.g. 1–2 more attempts), then fail.

Pseudocode:

text
if gr4vy.status == "authorization_declined" and gr4vy.error_code == "issuer_decline":
    show_message("Card was declined. Please try another card or payment method.")
    allow_limited_retries()

3.3 AVS / CSC / AVSCSC (address / CVV issues)

Radial:[docs.radial]

• AVS – AVS problem (address).
• CSC – CVV/CSC problem.
• AVSCSC – Both address and CVV issues.

Each has Radial guidance like “consumer fix required, resend” or “good, send order” depending on the detailed AVS/CVV codes.radial+1

Gr4vy equivalent:

• High‑level outcome: still either authorized or authorization_declined depending on the gateway.
• Detail:
  • avs_response_code – normalized AVS result.[docs.gr4vy]
  • cvv_response_code – normalized CVV result.[docs.gr4vy]

Suggested migration:

1. Move business logic off the Radial “AVS/CSC/AVSCSC” auth code, and onto AVS/CVV detail using Gr4vy’s fields.
2. Preserve the spirit of your existing rules. Example:

Radial rule example (old):

• If Radial response = AVS: show “Please check your billing address” and allow resend.
• If Radial response = CSC: show “Please check your CVC” and allow resend.
• If Radial response = AVSCSC: show combined error.

Gr4vy rule example (new):

text
if gr4vy.status == "authorization_declined":
    if gr4vy.cvv_response_code indicates "no match":
        show_message("Please check your card security code.")
    elif gr4vy.avs_response_code indicates "address mismatch":
        show_message("Please check your billing address.")
    else:
        show_generic_decline_message()

You’ll need an internal mapping from avs_response_code / cvv_response_code to “fix address”, “fix CVC”, or “generic decline” using Radial’s AVS/CVV documentation as reference.radial+1

3.4 PaymentProcessorTimeout (processor timeout)

Radial: PaymentProcessorTimeout – No response from processor in time.[docs.radial]

Gr4vy equivalent:

• Likely status = "authorization_error" or authorization_declined.
• error_code = "service_network_error" (timeout/unreachable).gr4vy+1

Recommended behavior (mirror Radial guidance):

• Implement a limited automatic retry (e.g. 1–3 times with backoff).
• If still failing, show a generic “technical issue” message and suggest trying again later or using another payment method.
• Do not automatically accept the order unless you have a downstream system that can safely retry later.

Pseudocode:

text
if gr4vy.error_code == "service_network_error":
    if retry_count < MAX_RETRIES:
        retry_authorization()
    else:
        show_message("We’re having trouble processing payments right now. Please try again later or use another method.")

3.5 Other Radial/processor faults

Radial has fault response codes for configuration issues, invalid requests, and internal errors.radial+1

Gr4vy equivalent:

• status = "authorization_error"
• error_code = "service_error" (unexpected upstream error).gr4vy+1

Recommended behavior:

• Treat as an internal error: log, alert, and show generic error to the shopper.
• Do not permit infinite retries; generally no more than 1–2, if any.

4. AVS & CVV details: preserving Radial‑style risk logic

If you have more granular risk rules today tied to Radial’s AVS/CVV tables (e.g. codes A, Y, Z, N, etc.), you can still preserve them by reading Gr4vy’s AVS/CVV fields and applying your own internal mapping.radial+2

4.1 Example: AVS

Radial AVS examples and guidance:

• Y – Street and 5‑digit postal match → “Good, send order.”
• N – No match on street or postal → “Consumer fix required, resend.”
• R – System unavailable/time‑out → “Accept; system issue.”

In Gr4vy:

• avs_response_code will contain a normalized code based on the PSP (Radial, Adyen, etc.).[docs.gr4vy]

Migration approach:

1. Build an internal mapping table:

text
avs_response_code = "Y" → riskCategory = GOOD
avs_response_code = "A" or "Z" → riskCategory = GOOD_WITH_NOTE
avs_response_code = "N" → riskCategory = CONSUMER_FIX_REQUIRED
avs_response_code = "R" or "G" or "S" or "U" → riskCategory = SYSTEM_ISSUE

1. Use riskCategory instead of Radial’s specific AVS response to drive your behavior.

4.2 Example: CVV

Radial CVV2 (CSC) result examples:[docs.radial]

• Code meaning “match” → treat as normal.
• “No match” → ask shopper to re‑enter CVC.
• “Not processed” or “issuer not certified” → usually treat as neutral/system issues.

In Gr4vy:

• cvv_response_code carries the equivalent result.[docs.gr4vy]

Migration approach is the same: build a small mapping table, then reuse your existing CVV‑driven flows.

5. Implementation checklist for migration

1. Identify all your current Radial‑based rules.
   • Search code for APPROVED, DECL, AVS, CSC, PaymentProcessorTimeout.
   • Also find AVS and CVV code usages.
2. Replace Radial response checks with Gr4vy status/error_code.
   • APPROVED → gr4vy.status == "authorized".
   • DECL* → status == "authorization_declined" && error_code == "issuer_decline".
   • PaymentProcessorTimeout → error_code == "service_network_error".
3. Move AVS/CVV rules to Gr4vy’s detail fields.
   • Replace direct Radial AVS/CVV constants with a small mapping off avs_response_code and cvv_response_code.
4. Log and monitor raw_response_code.
   • During early migration, log Gr4vy’s raw_response_code side‑by‑side with your Radial logs to verify that your new logic produces the same customer experience.
5. Test key scenarios end‑to‑end.
   • Approved transaction.
   • Issuer decline.
   • CVV mismatch.
   • Address mismatch.
   • Processor timeout / service network error.

If you share a specific snippet of your current Radial‑based decision tree (e.g. “we do X when DECLR and AVS = N”), I can help rewrite that in terms of Gr4vy’s status, error_code, avs_response_code, and cvv_response_code.

Support

For technical support, contact: support@radial.com