Can a Palm Vein SDK Capture Data Without an Algorithm Server?

“We already have our own backend. Can the terminal simply scan a palm and return the biometric data for us to process?”

This is a practical question for teams building palm vein payment, customer identification or access applications. Many developers expect a biometric SDK to work like a camera interface: capture the data, return it to the application and let the backend decide what happens next.

The current BioWavePass Large Scale SDK follows a server-based registration and identification workflow. It does not provide a standalone capture-only method that returns palm data without completing server-based registration.

Understanding this distinction before development helps your team select an appropriate integration approach.

What Does “Capture-Only” Mean?

A capture-only requirement usually describes the following behaviour:

1. The application activates the palm reader.
2. A user presents their palm.
3. The SDK returns biometric data immediately.
4. The application stores or forwards that data independently.
5. Server-side registration happens separately, if required.

This differs from the supported Large Scale SDK registration flow, where the terminal and algorithm service work together to complete registration.

The presence of a preview or scanning interface does not mean that the SDK exposes an independent method for retrieving biometric data.

Why Does the Large Scale SDK Need a Server URL?

The current Large Scale SDK requires a valid server URL for registration and identification.

That URL can point to:

• The Algorithm Server directly.
• Your backend, provided it implements the required interfaces and returns compatible responses.

The server connection is therefore part of the SDK workflow. It is not simply an optional destination for data after scanning.

If your project requires operation without any server connection, that requirement needs a separate technical assessment.

What Happens During Palm Registration?

Your platform first supplies a stable, unique user ID.

For example:

registerUserWithPalmData(userId = "customer-123")

This method does more than create an empty user record. It completes the palm registration process with the algorithm service and associates the registered palm data with your supplied ID.

Registered left and right palms can be mapped to the same user ID.

After registration succeeds, the SDK returns the registration biometric data.

The distinction is the timing: data is returned following successful registration, rather than through a separate capture-only call.

Can We Still Use Our Own Backend?

Yes. Your backend can sit between the terminal SDK and the Algorithm Server.

The supported flow is:

Terminal SDK → Your backend → Algorithm Server → Your backend → Terminal SDK

Your backend should expose the required operations for registration, query and deletion. It then calls the corresponding algorithm-service APIs and returns the responses in the format expected by the SDK.

This lets your platform coordinate biometric operations with its own business processes.

However, routing requests through your backend does not turn the SDK into an independent palm-capture tool. The algorithm service remains part of the supported workflow.

Three Requirements That Sound Similar but Are Different

Before choosing an architecture, separate these common requirements:

Clarifying which behaviour your project needs can prevent unnecessary development around an unsupported assumption.

Does Server-Based Recognition Mean Using the Supplier’s Public Cloud?

No. A requirement for an algorithm server does not mean that production must run on the supplier’s public cloud.

Public-cloud access is available for evaluation. Large-model private deployment is also available, allowing the algorithm service to run on customer-controlled infrastructure.

There are two separate questions:

• Does the SDK require an algorithm service? Yes, for the current registration and identification workflow.
• Must that service run in BioWavePass’s public-cloud testing environment? No. Production deployment can be planned separately.

Offline deployment preparation for a restricted network should also be distinguished from server-free operation. Preparing deployment resources offline does not remove the SDK’s need to reach the deployed algorithm service.

For Palm Payment, What Does Your Platform Control?

A palm vein payment application includes more than biometric capture and matching.

Your platform remains responsible for:

• Associating the supplied user ID with the correct customer account.
• Applying account and payment permissions.
• Initiating payment processing.
• Handling transaction approval or rejection.
• Showing the final payment result.

The algorithm service provides the biometric identification result used within that process.

For example, a successful palm match can identify the registered customer. Your payment platform must still determine whether the requested transaction can proceed.

Using the supported registration workflow does not transfer ownership of your payment logic to the biometric SDK.

What If Our Application Truly Needs Capture-Only Behaviour?

Describe the required behaviour before starting custom development.

Useful questions include:

• Do you need palm images, feature data or both?
• Must data be returned before any server operation?
• Will the terminal have access to an algorithm service?
• Why must capture and registration happen separately?
• What should happen if the server is unavailable?
• Which host platform and palm reader will be used?

These details help BioWavePass assess whether your requirement can be addressed through the standard workflow or needs additional development.

A separate assessment should not be interpreted as confirmation that a capture-only feature is already available.

Test the Standard Workflow First

The Large Scale SDK Demo and public-cloud testing environment are available before customers purchase the large-model algorithm.

Begin by completing the supplied registration and identification process with compatible sample hardware.

During testing, check:

1. How your platform supplies the user ID.
2. When registration completes.
3. Which data the SDK returns after success.
4. How identification results reach your application.
5. Whether your proposed backend preserves the expected responses.

This gives your developers a working reference before they introduce additional platform logic.

Keep Small and Large Model Assumptions Separate

BioWavePass’s Small Model and Large Model are entirely separate, decoupled systems.

The Small Model uses featureId to identify a palm. The Large Model uses a customer-supplied user_id to identify a user.

Their SDKs should not be used together in the same application build. Behaviour observed in one system should not be assumed to exist in the other.

This article describes the current Large Scale SDK.

Frequently Asked Questions

Is there a method that only scans a palm and returns its biometric data?

There is no standalone capture-only method in the current Large Scale SDK that returns palm data without completing the server registration flow.

Can we receive biometric data after registration?

Yes. The SDK returns registration biometric data after successful registration.

Can the SDK point to our backend?

Yes. Your backend must implement the required interfaces, communicate with the Algorithm Server and return responses in the SDK’s expected format.

Can the current Large Scale SDK register users without a server?

No. A valid server URL is required for the current registration and identification workflow.

Can the algorithm service run on customer-controlled infrastructure?

Yes. Large-model private deployment is available. This changes where the service runs, rather than removing the server requirement.

Discuss Your Palm Capture Requirements with BioWavePass

Before building around a capture-only assumption, confirm exactly when your application needs data and what it intends to do with it.

Share your hardware, platform, connectivity and registration requirements with BioWavePass. Our team can help clarify the standard evaluation path and identify any requirements that need a separate technical assessment.
Contact us via: https://biowavepass.com/palm-vein-integration-guide/