You can define various fields as part of your card design, including images and text and barcodes. These can be fixed and so appear on all cards, or can be input fields which can be specified for each individual card such as someone's name or their photo. Using the same input field name in more than one field means the same content appears in more than one place, so a name or ID number could be shown as text and included in a barcode, for example.
It is possible for one design to be derived from another, and so all of the fields of the parent design apply first. You can make such a design using the derive design button. You can then edit/add fields to the new design on top of the old design, or copy all fields over if you need to make an independent design. This is how standard designs are set up - making a derivative for you to create cards to print.
When adding a field, you can select the type of field. The main types are:-
By default the field name is the of a variable which can be set per card, e.g. Name, etc.
It is important to note that the same field name can appear on multiple fields. The variable only exists once, and so that same value can appear in multiple places and types. E.g. You could have Name in black text on the front, and also in a 1D barcode on the back, or encoded in a mag stripe track.
A field name that is just underscore _ is a fixed field. More generally any field starting with an underscore is a non variable field, and is normally one of the dynamic fields like _id.
There is a special case of fields starting double underscore __ - these are non printing fields, used for cosmetic artwork (e.g. stuff already on the card, such as SIMs).
Note that field names can exist to define variables which are not directly printed, but can be used for part of dynamic variables, etc.
Normally, a field with a normal name has a value from the variables for the individual card. The card design allows an example to be set and shown for the deck design. If a field is used as an image, the value is actually a hash of the uploaded image, and you have the option of uploading new images per card for such variables.
A field can, however, be multiple choice, with have a set of tags, each of which has its own value. When the variable matches the tag, the corresponding value is used instead. When entering values for a card the tags are shown as a pull down selection. If the value is not found it is used, unless a blank tag is defined as a default.
A field can also be conditional, such as a fixed header only shown if the corresponding value is set. Use a field name starting with ?, e.g. ?Name to show the value only if the corresponding variable is not blank.
A variety of 1D and 2D barcodes are available, including the common QR barcodes. If you need another format not listed, please do contact us. These can be fixed as part of the design, selected from multiple choice, or per card data. There are also systems to generate codes for VCARD and WIFI.
It is recommended than you do not include barcodes in images. This is because images will be scaled to fit and this can create aliasing effects on the bar code pixels, causing the size of barcode elements to not be exact. In most cases they will still read, especially QR codes (as they contain a lot of error correction). However, making the barcode more exact, and aligned exactly to the printer pixels and resolution, will provide the best quality barcode. When using the built in barcodes this is done automatically, and can mean the barcode may print slightly smaller that your design to use exact multiples of print pixels. The alignment options allow you to control how such barcodes are shown within a rectangle.
It is also important to ensure barcodes are printed with good contrast, i.e. avoid artwork behind the barcode. It is best to print on the black layer, with white behind.
All barcodes include a quiet area. For 1D barcodes this is normally at each end, and for 2D barcodes this is around the outside. This quiet area should be white like the background. It is a common mistake to print QR codes without the required 4 unit quiet zone around it - they are often incorrectly printed with a 1 unit white border. The system normally provides barcodes with the required quiet area. There are options for no quite versions, but these should only be used where you are including the required quiet area, but need the barcode content to be aligned with something else nicely. As such it is recommended you use the standard barcode with quiet area in your layout first, even if changing later to align the image nicely.
Images can be loaded as part of the design, covering the whole card, or a specific size/position. The card design can also define images as part of a multiple choice, so that a keyword or value per card can select an image to use. Images can also be loaded as per card items, e.g. photo for ID.
Images can be specified in a variety of formats include JPEG, PNG, GIF. It is recommended that images be provided to print at, at least, 600dpi. Images are scaled to fit. Note that the background image, with 1mm bleed area, ±1mm, at exactly 300dpi or 600dpi will be centred on the card and not scaled, so you can avoid any antialiasing or scaling effects.
A number of dynamic fields allow content to be created. These have a field name that starts with an underscore. The fields can be used in various ways, e.g. text, barcode, magstripe, etc.
The design allows you to see both sides of a card the way up you expect the card to be viewed. This makes design much easier, although you can rotate text and images, etc, if you need. To help with this, the design can be portrait or landscape.
When printing double sided, it matters how the artwork is printed, and this depends on long-edge-flip or short-edge-flip, i.e. how you turn the card to see the reverse side the right way up. This can be set in the card design. Obviously this impacts where a slot, magstripe, or SIM cutouts appear on the rear of the card design.
Because cards can have features like contacts and magstripes, you may also like to rotate the whole design to fit these features. This can be selected in the card design.
If you want a slot in the card, and have any additional features like SIM or Magstripe, you may need to try these settings to get the slot in the right place relative to these features. It is a good idea to get this right before making the artwork for your design.
A number of special field types exist which relate to the physical card.
You can set the position, side, rotation, and alignment of most field types.
The position defines where a rectangle for the field is located, and can be from either edge or centre of the card.
The position can also be relative to the previous field (and the order of fields can be changed within a colour/side). This is mainly intended for one field to be below another, and so the relative vertical position defines the gap between fields, however the relative horizontal position is from the other edge, e.g. +0mm from left is aligned to the left of the previous field (not the right). Relative position is from the previous field after any rotation was applied to it.
The field has a size, a width and height, before any rotation is applied. One or both of these can be left to be zero as automatic, depending on the type of field. In the case of an image such as a logo it works well to define one dimension and leave the other automatic, ensuring the image is not cropped. For a photo you may want to set both, cropping any over the edge whilst maintaining aspect ratio.
The rectangle can then be rotate in various ways - the alignment depends on the position, e.g. if position from left of card the left side will be maintained when rotated, adjusting the right hand side as needed, etc.
Within the rectangle it is possible to define alignment for various types of field, mainly text. This alignment applies before any rotation. When applied to images it indicates how the image is cropped to cover the rectangle. In the case of bar codes this relates to any additional space needed where the barcode format has to be smaller than specified to pixel align for printing.
You can select font and style and size of text as well as the format. For single line text the baseline of the text is the bottom of the position rectangle, for othe types the text is positioned within the rectangle. Alignment applies to lines within the text. You can wrap text or define a simple block of text. Automatic size is often sensible for any fixed text, but you want want to confine the text to a box for any per card fields.
For many things you can pick a colour for fill and outline. You can select one of the colours or enter #rrggbb or even #rrggbbaa. You can also enter some special colours, such as rainbow.
Remember that the card is made of layers - with the colour layer printed first, then the black layer printed on top. Any UV layer is then on top of this. If you use the PO layer, this inhibits printing of colour or black, so effectively prints white (note that it is not possible to print fine detail in the PO layer).
Please consider MIFARE classic to be insecure - they can be cracked with ease. I.e. treat much like printed QR codes or mag encoded, something that is machine readable but easily copied or changed.
We support MIFARE Classic cards, including allowing encoding of data in sectors and blocks:-
The MAD coding allows addition 4 character hex MAD to be specified on the end of the sector trailer hex key information. This is then encoded correctly (with info=00) in sector 0 blocks 1 and 2, and if using sectors from 16 then MAD2 data in blocks 0, 1, and 2 of sector 16, with correct CRC8. This allows you to simply define the MAD for each sector with the keys and we handle the rest. If you prefer, you can simply specify hex data for these sectors rather than using our MAD encoding system.
We also check consistency of access bits in all sector trailers, and required access bits and GPB byte for MAD usage in sector 0 and 16 trailer.
Hex data can be specified with spacing between bytes for easier formatting. Text data assumes utf8 coding.
Of all the cards we handle, the DESFire EV are the most secure. They include AES keys allowing secure authentication and communication to the card. The key has to be known by both ends (the card and the reading system), but as long as this is kept secret then they are secure. A card can contain multiple applications with multiple keys for different purposes.
We don't program DESFire cards as such, i.e. we don't load data on them like we do for MIFARE cards. However, we can provide one crucial security step by setting a random master key when printing a card, and providing that to you.
To understand how this works it is important to understand the security challenges of these systems. Obviously there is the possible risk of supply chain tampering, and the most secure approach it to obtain cards yourself; load a key you know; send to us for printing; and on return - authenticate the key you programmed. However, if you trust us to supply genuine cards there is still a security challenge.
Once the card has a key you can ensure all communications is secure, even if there is a man in the middle attack, or snooping. The key is used to ensure the card and reader are authentic (both know the key) and that communications is not changed, and that communications (such as setting new keys) is encrypted. This is one of the reasons these are good cards, as you can re-program them via a remote reader with no real risk.
However, that loading of an initial key is a vulnerability - that has to be done in a secure environment where there is no risk of snooping on the communications or a fake card being used. This is because new cards have a known key (all zero), and so snooping on the initial key setting gets you the new key, and then you can snoop on all further communications, and clone the card, and so on.
To provide this initial secure environment, we will create a random AES key and program your DESFire cards in the printer as part of printing. We send the card ID and the key (version and AES data) to you as a JSON object via https so you can record the key. We include the APIKEY in the Bearer header so that you know it is us. We don't record the key anywhere, but it is obviously good practice for you to set a new key once you physically get the card. Providing you trust us, and our card suppliers (please just ask, if you want detail) this gets you cards with that crucial initial key programming step already done.
The price for your card design is shown on the design edit pages. The cost depends on:-
The main place where you can reduce cost is double sided cards - the cost depends on how ribbons are used. So the cheapest double sided cards use colour on one side and black on the other allowing only one YMCK panel per card. We also have double black ribbons that mean colour+black on one side and only black on the other is cheaper than printing full colour+black on both sides.
Cards can be used in situations where security matters, especially any sort of identification card. For this reason, if you ask us to print anything that looks like an ID card, we will take extra measures to check you are entitled to the card. If you need ID cards in a hurry, pay us from a bank account in the same name as the organisation shown on the card.
For the avoidance of any doubt, we cannot guarantee to always get this right. We can refuse to print cards for any reason, and all we owe you is a refund of what you have paid. If we print your cards, you take responsibility (and indemnify us) for any liability including in relation fraud, copyright or trademark.
Please consider the following security advice when designing cards - and investigate security yourself to ensure you are happy with the security offered by printed cards.
| Edge to Edge printing | It is common for cheaper printers to be unable to print right to the edge of a card, so a design with blocks of colour or images that bleed over the edge can cost more to copy. This is just a matter of cost, and more expensive printers can print edge to edge. |
| Micro printing | We can print at 600dpi and so can print tiny lettering that is harder to print on a cheaper machine. Again, this is simply a matter of cost. However, microprinting can be harder to copy from a simple photograph. |
| UV fluorescent overlay | A UV overlay can be printed on a variety of printers, and again this is a simple matter of cost. However, it may not be obvious that there is a UV layer and so someone copying a card may not realise. It is also harder, or even impossible, to copy the UV layer from a simple photograph. |
| PO overlay | We can print in a protected overlay which prints white, and so can print white on white which you can see at the right angle in the light, and is slightly tactile. This is an unusual feature, but other printers could do this. This makes it harder to copy from a photograph. |
| Barcodes | Barcodes are easy to read and copy and offer little security. They are simply a convenience for machine readability. See note below on signing. |
| Mag stripe | Mag stripes are easy to read and copy with inexpensive equipment. They are simply a convenience for machine readability. They do offer protection of copying from a photograph, obviously, as the code cannot be seen. |
| RFID NTAG | NTAG codes are intended to be read, and easy to copy. They can hold more data though, so see note below on signing. Once again, someone copying a card may not be aware that you used a NTAG card, and they cannot copy from a photograph. |
| RFID MIFARE Classic | Please do not assume these are secure - there are simple tools that can extract keys in minutes. See note below on signing. |
| RFID MIFARE DESfire | DESFire with AES is generally considered reasonably secure, and for this reason we do not normally encode such cards - instead we will print them and record the card ID (and if you wish, set a master key) so you can encode the card matching the details printed on it when you get the printed cards from us. See above for more details. |
Some means of encoding allow a reasonable amount of data (RFID, and 2D barcodes) which could allow signing of data. This is, in itself, no protection against copying, but it can allow you to ensure false data is not deliberately encoded. This is not usually very useful for identification because of the ease with which it can be copied.