Getnet DocsGetnet Docs

Certification Process

What Is the Certification Process?

Before going live with your payment integration, you must complete a certification process to ensure your implementation meets GetNet’s technical, security, and user experience standards, as well as regulatory requirements. Once you have finalized the commercial agreements with GetNet’s sales team, the certification process begins when the GetNet integrations team contacts you to guide you through the technical validation. This process validates that your integration handles payments securely, provides a good user experience, and complies with industry best practices.

Step 1: Security Requirements

PCI DSS Certification

An active PCI DSS certificate is mandatory. This document must be obtained from the party responsible for capturing cardholder data—either your organization or a third-party provider. Once available, submit the certificate to the Integration Support Team for approval via email.

Sensitive Data Protection

Cardholder data must be handled with strict security measures:

  • Never display the full card number at any point in the transaction flow
  • Never store or display CVV data at any stage, including on transaction receipts
  • On vouchers or receipts, only display the BIN and the last four digits of the card number
  • Ensure all sensitive data is encrypted in transit and at rest

Step 2: User Interface Requirements

To ensure a seamless and transparent payment experience for your users, your integration must meet the following user interface requirements:

Payment Initiation and Branding

Before submitting a payment, display a clear and concise transaction summary to the user. Include appropriate payment gateway branding (such as the GetNet logo) depending on your integration context.

Terms and Conditions

Provide a clearly visible link allowing users to read and accept the terms and conditions before completing the payment.

Frequently Asked Questions (FAQ)

Include a section with frequently asked questions related to electronic payments. A suggested FAQ document is provided during the onboarding process.

Transaction History

Users must have access to a summary of their past purchases, which should include the following details:

  • Reference number
  • Date of the transaction
  • Amount (including currency)
  • Transaction status

Step 3: Technical Security Requirements

Your integration must implement technical security measures to protect sensitive data, prevent duplicate transactions, and ensure reliable payment processing. These requirements are essential for maintaining security compliance and providing a secure payment experience.

Secure Credential Storage

Credentials must be stored securely, either in a protected database with encryption or as environment variables. Secure configuration management systems may also be used. Under no circumstances should these credentials be exposed in source code, version control systems, or client-side code.

Payment Button Handling

To prevent accidental multiple charges, measures must be in place to avoid repeated submissions caused by double-clicking the payment button, network delays, or browser back/forward navigation issues.

Idempotency Control

The use of the idempotency_key field must be implemented to ensure that duplicate payment attempts are not processed more than once. This prevents accidental duplicate charges when network issues occur.

Handling of Pending Transactions

If a transaction remains in a pending state, the system must notify the user accordingly before allowing a new payment attempt to be initiated. Implement proper status tracking and user communication for pending transactions.

Step 4: Data Validation Requirements

Proper data validation ensures that payment information is collected accurately, securely, and in compliance with authentication requirements. Your integration must validate all input fields before submission and collect the necessary data for 3D Secure authentication when applicable.

Mandatory Fields for 3DS Authentication (if Applicable)

When implementing 3D Secure authentication, collect the following mandatory fields:

  • Cardholder’s email address
  • Full name
  • Phone number
  • IP address of the device used during the transaction

Recommended Fields for 3DS Authentication

To enhance security and improve authentication accuracy, also include billing address details:

  • City
  • Country
  • Address line
  • Postal code
  • State

Luhn Algorithm and CVV Validation

Card numbers must be validated using the Luhn algorithm (a mathematical formula used to validate identification numbers, such as credit card numbers, IMEI numbers, Social Security numbers, and others). The CVV field should accept numeric input only and must be rendered as a password-type field to protect sensitive data.

Field Validation Rules

  • First and last names: Must not contain special characters or numeric values
  • Email addresses: Must adhere to a valid email format
  • All required fields: Must be validated before submission

Step 5: Transaction Flow Testing

You must perform and document the following transaction scenarios:

Transaction TypeWhat to ValidateRequired Evidence
Approved / AcceptedDisplay status, message, description, date, total amount, and currencyPanel and frontend screenshots
Rejected / Denied / ErrorSame data as for an approved transactionPanel and frontend screenshots
PendingValidate matching initial and final statusEvidence before and after status change

Integration Logs

Maintain logs of all requests sent to the payment gateway. These logs are essential for troubleshooting, auditing, and validating your integration’s behavior.

Step 6: Additional Integrations

Webhook (Status Notifications)

You must expose 4 URLs during accreditation on the Digital Platform to receive asynchronous transaction status notifications. These webhooks enable real-time updates when transaction statuses change.

Probe / Cronjob

Implement a mechanism to handle pending transactions:

  • Simulate a pending transaction.
  • Manually update its status from the admin panel.
  • Verify that your website automatically reflects the status change.

Step 7: Transaction Data Requirements

Your integration must include complete and accurate transaction data to ensure proper processing, compliance with regional requirements, and successful payment handling. This includes payer and buyer information, unique transaction references, and any required tax or payment modifier details.

Payer and Buyer Information

Include data for both payer and buyer entities in the transaction flow when applicable.

Unique Transaction Reference

Each transaction must have a unique reference identifier to prevent duplicates and enable proper tracking.

Tax Handling

Verify whether any of the available countries require taxes to be broken down separately in the transaction data.

Payment Modifiers

Validate that required fields are included based on the type of financing or applicable taxes for your market.

Step 8: Transaction Reversal

If your integration supports transaction reversals or cancellations, these operations must be properly implemented and validated during the certification process. This ensures that cancellation requests are handled correctly and that status updates are accurately reflected in your system.

Cancellation Process

If you have implemented transaction reversals via API, this flow must also be validated during certification. Ensure that cancellation requests are handled correctly and status updates are reflected in your system.

Validation Checklist

Throughout the certification process, you are required to provide evidence of compliance. This can be submitted via:

  • Email documentation
  • Screenshots demonstrating functionality
  • Video recordings of user flows
  • Integration logs

If any requirement is not implemented, you must provide a justification explaining why. All submitted information is reviewed and validated by the Quality Assurance and Information Security teams.

See Also

For information about PCI DSS compliance requirements, see PCI Compliance (PCI DSS). For details about secure data handling, see Tokenization. To understand authentication requirements, see 3DS Authentication 2.0.